Selector cleanup

Alan Bateman Alan.Bateman at Sun.COM
Thu Jan 24 13:11:42 UTC 2008

Rémi Forax wrote:
> Hi all, i currently develop a small web server and  I think codes related
> to selectors can be improved just by changing some small pieces of code.
> To be crystal clear, i don't want to re-implement all selector related 
> stuffs but
> just patch some parts of the actual code.
> There are some allocations in JDK API  that can be removed,
> the code was badly retrofited to 1.5 and lot of field can be declared 
> final.
> Some methods/fields still 'use' raw types and doesn't take
> advantage of autoboxing.
You're right. Much of the code here dates back to 1.4 and we haven't 
gone back to clean-up things like this.

> Futhermore, there is some divergence between Windows and *nix
> code i don't understand.
> By example, WindowsSelectorImpl and PollSelectorImpl uses a pipe to
> implements wakeup but WindowsSelectorImpl  relies on Pipe
> and PollSelectorImpl on IOUtil.initPipe().
> I think this code should be the same.
Ideally we would use a socketpair for the wakeup mechanism but Windows 
doesn't support it. For this reason, Pipe is implemented as a loopback 
connection and this works okay for the wakeup mechanism too. One thing 
to mention is that PollSelectorImpl is only used now when running on the 
Linux 2.4 kernel (it's not used with the 2.6 kernel and isn't used on 
Solaris). I just mention this as someday it might become obsolete and we 
can remove it.

> in WindowsSelectorImpl:
>  - updateSelectedKeys() use an iterator to traverse the array
>    (an ArrayList). It should use an indexed loop instead
>    to avoid Iterator allocation.
>  - field threads should be declared as an ArrayList
>    because adjustThreadsCount() supose that i can be iterate
>    using an indexed loop.
>    Furthermore, it can be generified like this:
>    private final ArrayList<Thread> threads = new ArrayList<Thread>();
These clean-ups seem reasonable.

> - class FDMap,
>   I don't see why FdMap need to be a class, all methods can be moved
>   as member methods of WindowsSelectorImpl without problems.
>   Futhermore, the constructor of FdMap is private (get/put/remove too)
>   so the compiler stupidly inserts accessor methods (access$000 etc.).
>   Ok, the main point, here when the code was retrofited to 1.5,
>   The new Integer() was not transformed to use Integer.valueOf()
>   to share small integers and avoid allocation if file descriptor 
> value are small.
These are SOCKET types rather than file descriptors and unlikely to be 
in the range that Integer caches (actually it should be a Long but that 
is a story for another day).

> - In class MapEntry, ski should be declared final.
> - close(), set selectedKeys() to null doesn't allow the Set to be 
> collected
>    because publicSelectedKeys contains() a reference to it.
> in PollSelectorImpl:
>  - interruptLock should be final.
>  - close(), see WindowsSelectorImpl
> in EpollSelectorImpl:
>  - like in poll, interruptLock should be final.
>  - hashMap fdTokey should be generified and final.
>  - close(), see WindowsSelectorImpl
>  - implRegister/implDereg
>    - They should use Integer.valueOf() instead of new Integer().
>    - IOUtil.fdVal() is used spuriously, in implRegister but not
>      in implDereg.
These are integers so there could be some benefit (but probably very 
hard to measure).

>  - EPollArrayWrapper
>    - updateList is a LinkedList, a double linked list that stores 
> Updator object,
>      I think it's more efficient to add a field next in the Updator 
> object and
>      link updator by hand in order to avoid to create LinkedList$Entry .
Maybe but probably very hard to measure.

>   - Updataor.opcode and Updator.fd should be declared final.
>     - SelectorImpl:
>     key and selectedKeys should be LinkedHashSet instead of Set
>     because they are frequently iterated.
>   let discuss about that before I submit patchs.
The clean-ups you suggest seem reasonable so I would suggest going ahead 
and sending a patch. I'm happy to review and work with you to get the 
clean-ups integrated (once OpenJDK/jdk7 re-opens for changes of course).


PS: I don't know anything about your "small web server" but the simple 
server in may be useful.

More information about the core-libs-dev mailing list