Java NIO windows implementation

Question

While working on a project using the the NIO.2 AIO features I looked in the "old" NIO selector implementation and saw that on windows the default select-function is used which does not scale at all on windows due to a bad internal implementation. Everybody knows that on windows IOCP is the only real solution. Of course the callback-on-completion model does not fit into the NIO selector model but does this effectively mean that using NIO on windows is basically not a good idea ?

For instance: The new AIO features include an IOCP implementation.

This is especially true while using the latest Netty framework where support for AIO has been dropped. So Netty is not as fast on Windows as it could be ?

Scriptorium

Answer 1

NIO.2 uses IOCP

The call tree below demonstrates this for file i/o by featuring "Iocp" in several of the called class names, is from Java 7: NIO.2 File Channels on the test bench.

See also sun.nio.ch.Iocp.java, the "Windows implementation of AsynchronousChannelGroup encapsulating an I/O completion port".

NIO does not make use of IOCP, as it only supports "non-blocking i/o" (selectors), not "asynchronous i/o" (completion handlers) that was only added with NIO.2.

Cathar

Answer 2

I think you are confusing asynchronous with faster. Certainly NIO buffers are faster than serializing the same data that would be in the buffers, but many AIO techniques incur costs and delays that can give synchronous IO an advantage.

There was an article a while back that did some pretty good benchmarking of various IO techniques, and the results were (a bit) surprising. The Netty people probably decided to align with the better performing (blocking) IO models mentioned.

Scottiescottish

Great slides. But I'm specifically talking about windows here. The whole IO vs NIO issue is quite clear to me, NIO is much more about scalability. IO does perform better with < 1000 threads, NIO shows it's strength beyond 5k and more. But NIO does this on Linux with epoll which is a scalable selection method, as is kqueue. But on Windows the standard posix select function is really bad, due to implementation details of windows, so IOCP should always be used. – Scriptorium

There is a sun.nio.ch.Iocp class, so I'm not really understanding how NIO doesn't use IOCP. If it is not used in your environment, perhaps it can be enabled. Perhaps you are running a very old JVM. Perhaps something else. I just find it hard to believe that one would write a Java class and include it into the JVM support libraries just for the purpose of not making it accessible. – Scottiescottish

This class is only used by AsychronousChannelGroup which refers to AIO. The selector part of nio just use WindowsSelectorImpl. grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/… – Scriptorium

The article you mention compared blocking i/o and NIO's non-blocking i/o. It does not say anything about asynchronous i/o as implemented by NIO.2. – Cathar

Answer 3

The problem with IOCP and Java is that IOCP creates and manages threads. My understanding is that for IOCP to work in Java, the event system actually has to go through the Windows IOCP Thread, then scheduled on the Java ThreadPool for execution. This makes IOCP very very expensive to implement in Java versus C++/C#.

AIO was probably removed from Netty because no one wants to sacrifice 450,000 potential transactions just to use AIO versus NBIO. The transactional performance gap between AIO and NBIO is huge.

Cly

IOCP doesn't create threads – Soda