NIO.2 and GC activity

[Alan Bateman]

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.