harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@gmail.com>
Subject Re: [classlib][nio] epoll()-based Selector
Date Mon, 08 Oct 2007 09:33:42 GMT
Amazing work, Aleksey!

2007/10/8, Aleksey Shipilev <aleksey.shipilev@gmail.com>:
>
> Hi,
>
> This patch does not break anything that exists in classlib. Moreover,
> you will notify the difference only when you explicitly enable it with
> -
> Djava.nio.channels.spi.SelectorProvider=org.apache.harmony.nio.internal.EpollSelectorProviderImpl
> .
> Otherwise legacy SelectorProvider will be used - that would lead to
> default behavior. So the legacy implementation is preserved and used
> by default.


Seems RI[1] is adapative here, i.e., use epoll when 2.6 kernel is detected,
is it possible for Harmony to implement in similar way? Of course this can
be further work and doesn't necessary to prevent this patch to be applied.

Though have a quick look, I had a trivial issue in the patch, seems
EpollSelectionKeyImpl is just same with SelectionKeyImpl, in concept it's
reasonable because epoll() is just a different system call, and can be
transparent to Java API, so is it possible to just use SelectionKeyImpl in
EpollSelectorImpl?

[1]
http://java.sun.com/javase/6/docs/technotes/guides/io/enhancements.html#6

Thanks,
> Aleksey.
>
> 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
> >
>



-- 
Paulex Yang
China Software Development Lab
IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message