Selector cleanup

Rémi Forax forax at
Fri Jan 25 13:20:29 UTC 2008

Alan Bateman a écrit :
> Rémi Forax wrote:
>> ok, no valueOf(), i'm not an expert in Windows API.
>> But are you agree that class FdMap is not necessary.
> I agree and I assume you will replace it with an embedded Map. I 
> suspect it will be hard to see a difference (with the server VM anyway).
i'am pretty sure to see no perf difference but it will use less memory.
>> yes, very hard to mesure until you span 1k thread with one selector 
>> each.
> The typical NIO server tends to handle lots of concurrent connections 
> so with a relatively small number of threads (one per core for 
> example) and a small number of Selectors. It sounds like your server 
> might be different. Selector creation is relatively expensive so you 
> might run into issues there.
Selector are pre-created, during startup, so no problem.
We have observed that a selector doesn't work well with a lot of keys. 
That's why i use more threads than one per core.

I have found someone else saying the same thing:
>> btw if you take a look to EPollArrayWrapper, idlSet already use boxing.
> The idle set is almost always empty and an aside from one case, there 
> shouldn't be any boxing when the set is empty.
I not agree, reading the code, idle set is used when setInterestOps(0) 
is called.
I'm not sure that case is not frequent.
By example, you can found this code in grizzly:

  // disable OP_READ on key before doing anything else
  key.interestOps(key.interestOps() & (~SelectionKey.OP_READ));


>> Do you have any idea when openjdk will be reopen ?
> Mark and others are working hard to make this happen very soon. As I 
> understand it they have some infrastructure work to complete before 
> they can allow changesets to be pushed.
>> My small server is a research project that embeds a non-blocking 
>> parser in a webserver and
>> claims to have the same performance than grizzly. I will post a blog 
>> entry about it
>> when all benchmarks will be finished.
> I look forward to it.
> -Alan.

More information about the core-libs-dev mailing list