harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Wed, 30 Sep 2009 10:01:59 GMT
Jesse Wilson wrote:
> On Tue, Sep 29, 2009 at 1:20 AM, Regis <xu.regis@gmail.com> wrote:
>> I think "changes to the selected keys set" doesn't help to show more
>> things.
>> Because there is no much difference in processSelectResult. And the reason
>> for maintaining readableFDs/writableFDs and mapping is avoiding O(num(keys))
>> in Selector.select() [1]
>> What do you think?
> The optimizations moved work from selectNow() to register() and
> SelectionKey.interestOps(). Microbenchmarks that don't exercise those

Actually it's not "move", there is no O(numKeys) in both register() and 
SelectionKey.interestOps(). And it's possible to optimize modKey() update index 
directly instead of calling delKey() and addKey(). But I must admit it's 

> methods encourage the wrong kind of optimizations.

True, the benchmark from HY-4879 intend to show O(numKyes) is expensive, but 
SelectorBenchmark.java doesn't count SelectionKey.interestOps() neither, that's 
why I said we need more tests.

> And the current code is allocation heavy. In select cycles where the number
> of the ready keys changes, it allocates and copies O(numReadyKeys) memory.
> Unfortunately, the 4879 benchmark doesn't include any of these allocations.

This can be resolved by the way used in your new patch: set "flags" as field and 
reuse it.

Best Regards,

View raw message