You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Aleksey Shipilev <al...@gmail.com> on 2007/10/01 17:49:39 UTC
[classlib][nio] epoll()-based Selector
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
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Fedotov <al...@gmail.com>.
Great job, Aleksey! x320 looks fantastic.
I recall that one of my former colleagues hacked callback-based
dispatch into Linux kernel to process IP-telephony calls quickly. It's
nice to know that now anyone can use this feature just by calling
epoll.
On 10/1/07, Aleksey Shipilev <al...@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
>
--
With best regards,
Alexei,
ESSD, Intel
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Zakharov <al...@gmail.com>.
AFAIK Harmony snapshots will not work on pre-2.6 kernels anyway since
DRLVM has some issues with it. For details please see an old
discussion at [1] and especially Salikh's reply at [2]. As far as I
understand the issue is still relevant for the current version of
DRLVM, at least I haven't seen any discussions about it since then.
[1] http://gmane.comp.java.harmony.devel/23045
[2] http://gmane.comp.java.harmony.devel/23167
With Best Regards,
Alexei
2007/10/8, Alexei Fedotov <al...@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 <fi...@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 <al...@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 <al...@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
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Fedotov <al...@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 <fi...@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 <al...@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 <al...@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
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
+1 to postpone runtime check implementation.
I have verified that the patch is applied correctly.
Thanks,
Aleksey.
On 10/15/07, Alexei Zakharov <al...@gmail.com> wrote:
> Aleksey,
>
> I've committed your additional patch with a build-time check.
> Therefore, now Harmony won't complain about unresolved symbols on 2.4
> system if it was built using 2.4 kernel headers. However, we still
> have issues with running our regular epoll-based snapshots on 2.4
> systems since we don't have a runtime check. I'm not advocating
> implementing such check immediately. Probably for now it is enough
> just to describe this limitation somewhere on our site or wiki.
>
> Thanks,
> Alexei
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Zakharov <al...@gmail.com>.
Aleksey,
I've committed your additional patch with a build-time check.
Therefore, now Harmony won't complain about unresolved symbols on 2.4
system if it was built using 2.4 kernel headers. However, we still
have issues with running our regular epoll-based snapshots on 2.4
systems since we don't have a runtime check. I'm not advocating
implementing such check immediately. Probably for now it is enough
just to describe this limitation somewhere on our site or wiki.
Thanks,
Alexei
2007/10/12, Aleksey Shipilev <al...@gmail.com>:
> Hi again,
>
> I have attached the patch for build-time check to JIRA [1]. It fails
> on older kernels as:
>
> <us...@box> ~ashipile/jre-r582823-work/bin/java
> -Djava.nio.channels.spi.SelectorProvider=org.apache.harmony.nio.internal.EpollSelectorProviderImpl
> selectnow
> Server: Opening selector
> Now using EpollSelectorProvider
> No epoll facility support, please make sure you have build and run on
> 2.6.x kernel
> ---- exit ---
>
> [1] https://issues.apache.org/jira/secure/attachment/12367643/selectors-epoll-6-linux2.4fallback.patch
>
> Thanks,
> Aleksey.
>
> On 10/12/07, Aleksey Shipilev <al...@gmail.com> wrote:
> > Tim,
> >
> > I agree with your approach. I will create epoll_* stubs that would
> > fail gently when called and make the preprocessor branch to compile
> > them on 2.4.
> >
> > Thanks,
> > Aleksey.
> >
> > On 10/12/07, Tim Ellison <t....@gmail.com> wrote:
> > > I agree that we should continue to support 2.4 kernels, especially since
> > > the original (non /sys/epoll code already exists in harmony).
> > >
> > > Therefore I suggest we need both compile time and runtime checks, i.e.
> > >
> > > #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
> > > // include the epoll-based headers here
> > > #else
> > > // include stubs to allow the epoll code to compile
> > > #endif
> > >
> > > then at runtime go down the correct linux version path for implementing
> > > the select functionality either using select or epoll.
> > >
> > > Does that make sense?
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
Hi again,
I have attached the patch for build-time check to JIRA [1]. It fails
on older kernels as:
<us...@box> ~ashipile/jre-r582823-work/bin/java
-Djava.nio.channels.spi.SelectorProvider=org.apache.harmony.nio.internal.EpollSelectorProviderImpl
selectnow
Server: Opening selector
Now using EpollSelectorProvider
No epoll facility support, please make sure you have build and run on
2.6.x kernel
---- exit ---
[1] https://issues.apache.org/jira/secure/attachment/12367643/selectors-epoll-6-linux2.4fallback.patch
Thanks,
Aleksey.
On 10/12/07, Aleksey Shipilev <al...@gmail.com> wrote:
> Tim,
>
> I agree with your approach. I will create epoll_* stubs that would
> fail gently when called and make the preprocessor branch to compile
> them on 2.4.
>
> Thanks,
> Aleksey.
>
> On 10/12/07, Tim Ellison <t....@gmail.com> wrote:
> > I agree that we should continue to support 2.4 kernels, especially since
> > the original (non /sys/epoll code already exists in harmony).
> >
> > Therefore I suggest we need both compile time and runtime checks, i.e.
> >
> > #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
> > // include the epoll-based headers here
> > #else
> > // include stubs to allow the epoll code to compile
> > #endif
> >
> > then at runtime go down the correct linux version path for implementing
> > the select functionality either using select or epoll.
> >
> > Does that make sense?
> >
> > Tim
> >
>
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
Tim,
I agree with your approach. I will create epoll_* stubs that would
fail gently when called and make the preprocessor branch to compile
them on 2.4.
Thanks,
Aleksey.
On 10/12/07, Tim Ellison <t....@gmail.com> wrote:
> I agree that we should continue to support 2.4 kernels, especially since
> the original (non /sys/epoll code already exists in harmony).
>
> Therefore I suggest we need both compile time and runtime checks, i.e.
>
> #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
> // include the epoll-based headers here
> #else
> // include stubs to allow the epoll code to compile
> #endif
>
> then at runtime go down the correct linux version path for implementing
> the select functionality either using select or epoll.
>
> Does that make sense?
>
> Tim
>
Re: [classlib][nio] epoll()-based Selector
Posted by Tim Ellison <t....@gmail.com>.
Aleksey Shipilev wrote:
> Hi,
>
> Because 2.4.x kernel tree is still alive, maintained and used (rarely,
> but there are some), I would pretend that 2.4 still exists and try to
> make sure my code expect this and let the user know that epoll is not
> working on 2.4.
>
> See http://kerneltrap.org/node/14003 to make sure that 2.4 is still alive. :)
I agree that we should continue to support 2.4 kernels, especially since
the original (non /sys/epoll code already exists in harmony).
Therefore I suggest we need both compile time and runtime checks, i.e.
#if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
// include the epoll-based headers here
#else
// include stubs to allow the epoll code to compile
#endif
then at runtime go down the correct linux version path for implementing
the select functionality either using select or epoll.
Does that make sense?
Tim
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
Hi,
Because 2.4.x kernel tree is still alive, maintained and used (rarely,
but there are some), I would pretend that 2.4 still exists and try to
make sure my code expect this and let the user know that epoll is not
working on 2.4.
See http://kerneltrap.org/node/14003 to make sure that 2.4 is still alive. :)
Thanks,
Aleksey.
On 10/12/07, Alexei Fedotov <al...@gmail.com> wrote:
> BTW, does one consider forgetting of 2.4 kernels? This would be the
> most effective solution measured in lines of code. :-)
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Fedotov <al...@gmail.com>.
Hello,
> If we will implement automatic switching to the epoll, then
we implement runtime check and fail gently.
BTW, does one consider forgetting of 2.4 kernels? This would be the
most effective solution measured in lines of code. :-)
Thanks.
On 10/12/07, Aleksey Shipilev <al...@gmail.com> wrote:
> Alexei,
>
> That's simple - if the have no _runtime_ kernel check and enable
> EpollSelectionProvider then we will fail with "unresolved symbol:
> epoll_*". More cleaner way will be to provide some runtime check and
> fail with some clean message describing lack of epoll facility in the
> running kernel.
>
> AFAIU, both ways should not confuse the user since epoll is turned on
> manually. If we will implement automatic switching to the epoll, then
> we implement runtime check and fail gently.
>
> Thanks,
> Aleksey.
>
> On 10/12/07, Alexei Zakharov <al...@gmail.com> wrote:
> > Another question is what we should do if somebody tries to use our
> > regular snapshot (that was built on 2.6+ kernel) on the machine with
> > older kernel.
>
--
With best regards,
Alexei,
ESSD, Intel
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
Alexei,
That's simple - if the have no _runtime_ kernel check and enable
EpollSelectionProvider then we will fail with "unresolved symbol:
epoll_*". More cleaner way will be to provide some runtime check and
fail with some clean message describing lack of epoll facility in the
running kernel.
AFAIU, both ways should not confuse the user since epoll is turned on
manually. If we will implement automatic switching to the epoll, then
we implement runtime check and fail gently.
Thanks,
Aleksey.
On 10/12/07, Alexei Zakharov <al...@gmail.com> wrote:
> Another question is what we should do if somebody tries to use our
> regular snapshot (that was built on 2.6+ kernel) on the machine with
> older kernel.
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Zakharov <al...@gmail.com>.
Gentlemen,
I agree with Aleksey that we could try to solve this issue by
inserting a compile-time check. Is it possible to configure default
providers during the build time? If so then we probably don't need
runtime check at all since epoll-based provider will never be called
by old-kernel-based version of Harmony snapshot. And the following
directives should help in case if the provider is instantiated
manually via -Djava.nio.channels.spi.SelectorProvider:
> > > #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
> > > // do some epoll activity here
> > > #else
> > > printf("Error: epoll facility is not implemented, please rebuild on
> > > newer kernel\n");
> > > #endif
Another question is what we should do if somebody tries to use our
regular snapshot (that was built on 2.6+ kernel) on the machine with
older kernel.
Regards,
Alexei
2007/10/12, Aleksey Shipilev <al...@gmail.com>:
> Alexei,
>
> That's build time check, and it solves the problem with building on
> 2.4.x kernels. I'm proposing the way we could detect the kernel
> version at the _build_ time and avoid compiling against non-existing
> API: let preprocessor detect version and replace epoll code with some
> message that "we have failed to find appropriate api during build,
> please rebuild us on 2.6.x kernel!" if necessary.
>
> I don't know how to make a runtime check yet, and runtime check is
> really nice-to-have feature that does not break anything seriously. In
> contrary, lack of build-time check will lead to failure while
> compiling on 2.4.
>
> Thanks,
> Aleksey.
>
> On 10/12/07, Alexei Fedotov <al...@gmail.com> wrote:
> > Alexei,
> >
> > I fully support your course of taking advantage of new OS features.
> > Who now recalls what DOS/4GW [1] is?
> >
> > Your patch is a bit confusing. Do you intend to add a runtime check or
> > a compile-time one? The compile time check is much simpler, but in
> > this case #error looks much more suitable then print. The runtime
> > check requires runtime comparison, and it will work with pre-built
> > binaries.
> >
> > Thanks.
> >
> > [1] http://en.wikipedia.org/wiki/DOS4GW
> >
> > On 10/12/07, Aleksey Shipilev <al...@gmail.com> wrote:
> > > Alexei,
> > >
> > > Thanks! The patch was applied OK.
> > >
> > > So now we have two main issues:
> > > 1. We need to detect the kernel at the build time and prevent
> > > breaking the compilation due to lack of epoll kernel API.
> > > 2. We need to detect the kernel at the run time and switch on
> > > EpollSelectorProviderImpl.
> > >
> > > For (1) I propose to include <linux/version.h> and then:
> > >
> > > #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
> > > // do some epoll activity here
> > > #else
> > > printf("Error: epoll facility is not implemented, please rebuild on
> > > newer kernel\n");
> > > #endif
> > >
> > > If it sounds right, I will go ahead and make the patch for it.
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > On 10/11/07, Alexei Zakharov <al...@gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > FYI yesterday I've committed Aleksey's patch for HARMONY-4879.
> > > > However, I afraid in spite of the fact that new epoll-based provider
> > > > is disabled by default corresponding native sources simply cannot be
> > > > compiled if kernel's version is less than 2.5.44 because of unresolved
> > > > references to epoll_ctl. According to manual: " epoll(7) is a new API
> > > > introduced in Linux kernel 2.5.44. Its interface should be finalized
> > > > in Linux kernel 2.5.66." Thus, it looks like we should detect kernel
> > > > version during the build time via "uname --kernel-release" or
> > > > something like it. Did I miss something?
> > > >
> > > > Thanks,
> > > > Alexei
> > > >
> > > > 2007/10/11, Tim Ellison <t....@gmail.com>:
> > > > > Apologies for the late response ... still catching up.
> > > > >
> > > > > Aleksey Shipilev wrote:
> > > > > > Hi, Paulex,
> > > > > >
> > > > > >> Amazing work, Aleksey!
> > > > > > Thanks, I was waiting for it :)
> > > > > >
> > > > > >> 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.
> > > > > > I believe it could be done in launcher which could detect the kernel
> > > > > > where Harmony starts and then instantiate right SelectorProvider. I
> > > > > > don't know the details for Harmony launcher though, it's just the
> > > > > > guess. This is in some way contrary with portlib implementation - we
> > > > > > could even implement optimized versions for Selector for Windows and
> > > > > > Linux separately.
> > > > >
> > > > > The launcher would not be the right place to detect the kernel version,
> > > > > since we would want this to work in all places that the NIO code is
> > > > > used, even when people are not using our launcher.
> > > > >
> > > > > Regards,
> > > > > Tim
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
Alexei,
That's build time check, and it solves the problem with building on
2.4.x kernels. I'm proposing the way we could detect the kernel
version at the _build_ time and avoid compiling against non-existing
API: let preprocessor detect version and replace epoll code with some
message that "we have failed to find appropriate api during build,
please rebuild us on 2.6.x kernel!" if necessary.
I don't know how to make a runtime check yet, and runtime check is
really nice-to-have feature that does not break anything seriously. In
contrary, lack of build-time check will lead to failure while
compiling on 2.4.
Thanks,
Aleksey.
On 10/12/07, Alexei Fedotov <al...@gmail.com> wrote:
> Alexei,
>
> I fully support your course of taking advantage of new OS features.
> Who now recalls what DOS/4GW [1] is?
>
> Your patch is a bit confusing. Do you intend to add a runtime check or
> a compile-time one? The compile time check is much simpler, but in
> this case #error looks much more suitable then print. The runtime
> check requires runtime comparison, and it will work with pre-built
> binaries.
>
> Thanks.
>
> [1] http://en.wikipedia.org/wiki/DOS4GW
>
> On 10/12/07, Aleksey Shipilev <al...@gmail.com> wrote:
> > Alexei,
> >
> > Thanks! The patch was applied OK.
> >
> > So now we have two main issues:
> > 1. We need to detect the kernel at the build time and prevent
> > breaking the compilation due to lack of epoll kernel API.
> > 2. We need to detect the kernel at the run time and switch on
> > EpollSelectorProviderImpl.
> >
> > For (1) I propose to include <linux/version.h> and then:
> >
> > #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
> > // do some epoll activity here
> > #else
> > printf("Error: epoll facility is not implemented, please rebuild on
> > newer kernel\n");
> > #endif
> >
> > If it sounds right, I will go ahead and make the patch for it.
> >
> > Thanks,
> > Aleksey.
> >
> > On 10/11/07, Alexei Zakharov <al...@gmail.com> wrote:
> > > Hi all,
> > >
> > > FYI yesterday I've committed Aleksey's patch for HARMONY-4879.
> > > However, I afraid in spite of the fact that new epoll-based provider
> > > is disabled by default corresponding native sources simply cannot be
> > > compiled if kernel's version is less than 2.5.44 because of unresolved
> > > references to epoll_ctl. According to manual: " epoll(7) is a new API
> > > introduced in Linux kernel 2.5.44. Its interface should be finalized
> > > in Linux kernel 2.5.66." Thus, it looks like we should detect kernel
> > > version during the build time via "uname --kernel-release" or
> > > something like it. Did I miss something?
> > >
> > > Thanks,
> > > Alexei
> > >
> > > 2007/10/11, Tim Ellison <t....@gmail.com>:
> > > > Apologies for the late response ... still catching up.
> > > >
> > > > Aleksey Shipilev wrote:
> > > > > Hi, Paulex,
> > > > >
> > > > >> Amazing work, Aleksey!
> > > > > Thanks, I was waiting for it :)
> > > > >
> > > > >> 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.
> > > > > I believe it could be done in launcher which could detect the kernel
> > > > > where Harmony starts and then instantiate right SelectorProvider. I
> > > > > don't know the details for Harmony launcher though, it's just the
> > > > > guess. This is in some way contrary with portlib implementation - we
> > > > > could even implement optimized versions for Selector for Windows and
> > > > > Linux separately.
> > > >
> > > > The launcher would not be the right place to detect the kernel version,
> > > > since we would want this to work in all places that the NIO code is
> > > > used, even when people are not using our launcher.
> > > >
> > > > Regards,
> > > > Tim
> > >
> >
>
>
> --
> With best regards,
> Alexei,
> ESSD, Intel
>
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Fedotov <al...@gmail.com>.
Alexei,
I fully support your course of taking advantage of new OS features.
Who now recalls what DOS/4GW [1] is?
Your patch is a bit confusing. Do you intend to add a runtime check or
a compile-time one? The compile time check is much simpler, but in
this case #error looks much more suitable then print. The runtime
check requires runtime comparison, and it will work with pre-built
binaries.
Thanks.
[1] http://en.wikipedia.org/wiki/DOS4GW
On 10/12/07, Aleksey Shipilev <al...@gmail.com> wrote:
> Alexei,
>
> Thanks! The patch was applied OK.
>
> So now we have two main issues:
> 1. We need to detect the kernel at the build time and prevent
> breaking the compilation due to lack of epoll kernel API.
> 2. We need to detect the kernel at the run time and switch on
> EpollSelectorProviderImpl.
>
> For (1) I propose to include <linux/version.h> and then:
>
> #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
> // do some epoll activity here
> #else
> printf("Error: epoll facility is not implemented, please rebuild on
> newer kernel\n");
> #endif
>
> If it sounds right, I will go ahead and make the patch for it.
>
> Thanks,
> Aleksey.
>
> On 10/11/07, Alexei Zakharov <al...@gmail.com> wrote:
> > Hi all,
> >
> > FYI yesterday I've committed Aleksey's patch for HARMONY-4879.
> > However, I afraid in spite of the fact that new epoll-based provider
> > is disabled by default corresponding native sources simply cannot be
> > compiled if kernel's version is less than 2.5.44 because of unresolved
> > references to epoll_ctl. According to manual: " epoll(7) is a new API
> > introduced in Linux kernel 2.5.44. Its interface should be finalized
> > in Linux kernel 2.5.66." Thus, it looks like we should detect kernel
> > version during the build time via "uname --kernel-release" or
> > something like it. Did I miss something?
> >
> > Thanks,
> > Alexei
> >
> > 2007/10/11, Tim Ellison <t....@gmail.com>:
> > > Apologies for the late response ... still catching up.
> > >
> > > Aleksey Shipilev wrote:
> > > > Hi, Paulex,
> > > >
> > > >> Amazing work, Aleksey!
> > > > Thanks, I was waiting for it :)
> > > >
> > > >> 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.
> > > > I believe it could be done in launcher which could detect the kernel
> > > > where Harmony starts and then instantiate right SelectorProvider. I
> > > > don't know the details for Harmony launcher though, it's just the
> > > > guess. This is in some way contrary with portlib implementation - we
> > > > could even implement optimized versions for Selector for Windows and
> > > > Linux separately.
> > >
> > > The launcher would not be the right place to detect the kernel version,
> > > since we would want this to work in all places that the NIO code is
> > > used, even when people are not using our launcher.
> > >
> > > Regards,
> > > Tim
> >
>
--
With best regards,
Alexei,
ESSD, Intel
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
Alexei,
Thanks! The patch was applied OK.
So now we have two main issues:
1. We need to detect the kernel at the build time and prevent
breaking the compilation due to lack of epoll kernel API.
2. We need to detect the kernel at the run time and switch on
EpollSelectorProviderImpl.
For (1) I propose to include <linux/version.h> and then:
#if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
// do some epoll activity here
#else
printf("Error: epoll facility is not implemented, please rebuild on
newer kernel\n");
#endif
If it sounds right, I will go ahead and make the patch for it.
Thanks,
Aleksey.
On 10/11/07, Alexei Zakharov <al...@gmail.com> wrote:
> Hi all,
>
> FYI yesterday I've committed Aleksey's patch for HARMONY-4879.
> However, I afraid in spite of the fact that new epoll-based provider
> is disabled by default corresponding native sources simply cannot be
> compiled if kernel's version is less than 2.5.44 because of unresolved
> references to epoll_ctl. According to manual: " epoll(7) is a new API
> introduced in Linux kernel 2.5.44. Its interface should be finalized
> in Linux kernel 2.5.66." Thus, it looks like we should detect kernel
> version during the build time via "uname --kernel-release" or
> something like it. Did I miss something?
>
> Thanks,
> Alexei
>
> 2007/10/11, Tim Ellison <t....@gmail.com>:
> > Apologies for the late response ... still catching up.
> >
> > Aleksey Shipilev wrote:
> > > Hi, Paulex,
> > >
> > >> Amazing work, Aleksey!
> > > Thanks, I was waiting for it :)
> > >
> > >> 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.
> > > I believe it could be done in launcher which could detect the kernel
> > > where Harmony starts and then instantiate right SelectorProvider. I
> > > don't know the details for Harmony launcher though, it's just the
> > > guess. This is in some way contrary with portlib implementation - we
> > > could even implement optimized versions for Selector for Windows and
> > > Linux separately.
> >
> > The launcher would not be the right place to detect the kernel version,
> > since we would want this to work in all places that the NIO code is
> > used, even when people are not using our launcher.
> >
> > Regards,
> > Tim
>
Re: [classlib][nio] epoll()-based Selector
Posted by Alexei Zakharov <al...@gmail.com>.
Hi all,
FYI yesterday I've committed Aleksey's patch for HARMONY-4879.
However, I afraid in spite of the fact that new epoll-based provider
is disabled by default corresponding native sources simply cannot be
compiled if kernel's version is less than 2.5.44 because of unresolved
references to epoll_ctl. According to manual: " epoll(7) is a new API
introduced in Linux kernel 2.5.44. Its interface should be finalized
in Linux kernel 2.5.66." Thus, it looks like we should detect kernel
version during the build time via "uname --kernel-release" or
something like it. Did I miss something?
Thanks,
Alexei
2007/10/11, Tim Ellison <t....@gmail.com>:
> Apologies for the late response ... still catching up.
>
> Aleksey Shipilev wrote:
> > Hi, Paulex,
> >
> >> Amazing work, Aleksey!
> > Thanks, I was waiting for it :)
> >
> >> 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.
> > I believe it could be done in launcher which could detect the kernel
> > where Harmony starts and then instantiate right SelectorProvider. I
> > don't know the details for Harmony launcher though, it's just the
> > guess. This is in some way contrary with portlib implementation - we
> > could even implement optimized versions for Selector for Windows and
> > Linux separately.
>
> The launcher would not be the right place to detect the kernel version,
> since we would want this to work in all places that the NIO code is
> used, even when people are not using our launcher.
>
> Regards,
> Tim
Re: [classlib][nio] epoll()-based Selector
Posted by Tim Ellison <t....@gmail.com>.
Apologies for the late response ... still catching up.
Aleksey Shipilev wrote:
> Hi, Paulex,
>
>> Amazing work, Aleksey!
> Thanks, I was waiting for it :)
>
>> 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.
> I believe it could be done in launcher which could detect the kernel
> where Harmony starts and then instantiate right SelectorProvider. I
> don't know the details for Harmony launcher though, it's just the
> guess. This is in some way contrary with portlib implementation - we
> could even implement optimized versions for Selector for Windows and
> Linux separately.
The launcher would not be the right place to detect the kernel version,
since we would want this to work in all places that the NIO code is
used, even when people are not using our launcher.
Regards,
Tim
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@gmail.com>.
Hi, Paulex,
> Amazing work, Aleksey!
Thanks, I was waiting for it :)
> 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.
I believe it could be done in launcher which could detect the kernel
where Harmony starts and then instantiate right SelectorProvider. I
don't know the details for Harmony launcher though, it's just the
guess. This is in some way contrary with portlib implementation - we
could even implement optimized versions for Selector for Windows and
Linux separately.
> 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?
That was done for compatibility across different Selector
implementations. Current version of legacy SelectionKeyImpl lack some
functionality: for example, EpollSelectionKeyImpl stores internal
index in the its fields and also have the callbacks to the Selector
for handling key modification events. Legacy selector does not
provide the targets for that callbacks (see modKey()), so I had to
fork the SelectionKeyImpl and stick it to EpollSelectorImpl
explicitly. However, if we will have [1] committed to the trunk, we
could merge the implementations together, though I bet to leave the
separate implementations.
[1] https://issues.apache.org/jira/browse/HARMONY-4869
Re: [classlib][nio] epoll()-based Selector
Posted by Yang Paulex <pa...@gmail.com>.
Amazing work, Aleksey!
2007/10/8, Aleksey Shipilev <al...@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 <fi...@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 <al...@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 <al...@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
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@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.
Thanks,
Aleksey.
On 10/8/07, Jimmy,Jing Lv <fi...@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 <al...@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 <al...@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
>
Re: [classlib][nio] epoll()-based Selector
Posted by "Jimmy,Jing Lv" <fi...@gmail.com>.
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 <al...@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 <al...@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
Re: [classlib][nio] epoll()-based Selector
Posted by Aleksey Shipilev <al...@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 <al...@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
>