Leon Finker wrote:
Hi,
I would like to provide feedback on NIO.2 based on the specs, and what
I’ve been reading about the implementation.
:
The main point is to eliminate the enormous amount of Future and any
dependant
objects creation for async send/recv when dealing with thousands of
connections on a server.
Whether the return should be void, this, or Future<V> is a reasonable
question to ask. The reason it is currently Future<V> is mostly to allow
for cancellation. In any case, where I/O operations do not complete
immediately then the context must be recorded so that it can be used
later when the I/O completes. Even if the signature had a void type then
some objects are required (timers for example). This has not been a
problem to date. I don't have much experience with .NET to comment on
the problems you observed but HotSpot and other modern VMs use
generational collectors that are specifically designed to work best when
the majority of objects are short lived. A possible concern of course
for asynchronous I/O is the case where I/O operations do not complete
quickly, and any objects allocated to the context for the I/O (timers
for example) survive just long enough to get promoted into the tenured
generation. There are quite a few people trying out this API and it
would be good to get feedback and other performance results to see
whether GC is a problem or not.
2. Is NIO.2 on windows based on IOCP?
The AsynchronousChannel implementations (except
AsynchronousDatagramChannel) and the WatchService implementation in the
file system API use IOCP.
-Alan.
13 messages in net.java.openjdk.nio-discussRe: NIO.2 and GC activity
