Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <16054505.1192720430859.JavaMail.jira@brutus>
Date: Thu, 18 Oct 2007 08:13:50 -0700 (PDT)
From: "Tim Ellison (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Resolved: (HARMONY-4869) [classlib][nio][performance]
 Selector improvements: moving away from O(n) at Java layer, part 1
In-Reply-To: <4521034.1190909930977.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Ellison resolved HARMONY-4869.
----------------------------------

    Resolution: Fixed

Thanks Aleksey.

Patch applied with minor code formatting changes(*) to NIO module at repo revision r586000.

Please check it was applied as you expected.

(*) Tabs yuk!

> [classlib][nio][performance] Selector improvements: moving away from O(n) at Java layer, part 1
> -----------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-4869
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4869
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: all
>            Reporter: Aleksey Shipilev
>            Assignee: Tim Ellison
>         Attachments: selectors-JL-O1.patch
>
>
> Current implementation of java.nio.channels.Selector is O(n) for Selector.select() operation. 
> There are several causes:
>  1. "keys" is the HashSet, so we spend time on iterating over it
>  2. "keys" are iterated on every select() to prepare the readable and writable arrays for native call
> This patch includes a bunch of optimizations:
>  1. Creates hashCode() and equals() for SelectionKeyImpl to get rid of calling _native_ identityHashCode()
>  2. Changes the internal representation of keys to SelectionKeyImpl[] and adds logic for on-the-fly maintenance
>  3. Adds on-the-fly maintenance for readable and writable arrays, making them prepared right away for every select()
>  4. Adds indexes for easy mapping "keys<->FD"
>  5. Optimizes hotpath in processResults().
> Keeping in mind that count(register) <= count(select), we sure that moving key set maintenance to register() is performance-safe.
> Thus, we simplify one part of Selector.select() call from being O(n) in the Java layer. There are also processResults() scales as O(n) and still portlib and native layers too - they're going to be optimized later too.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.