NIO.2 and GC activity

[Leon Finker]

I agree it would be great if someone could provide feedback on GC activity
under stress with NIO2. 

As for the cancelation, please correct me if I'm wrong, but I personally
have not seen a single case when Cancel would be used by developers to
cancel the recv/send requests on a socket. Usually the assumption is that
closing the sockets cancels any pending requests. The asynchronous model
lends itself to the following usage: schedule one or a few operations and
get completion callback, then schedule more. If developers normally split up
the data in fixed 2k/4k buffers, what would it mean to cancel the request?
What if some of the buffers (that makes up a fully formed message) already
went out... (again please correct me if I'm wrong) but I think cancel for
sockets is a luxury that probably will not be used by developers.

As for the context information recording the operation, it is possible for
NIO2 API to take this context instead of returning new one each time. Then
developers can reuse same context information per operation per connection.
Thank you for the feedback!

-----Original Message-----
From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] 
Sent: Sunday, January 18, 2009 8:11 AM
To: Leon Finker
Cc: nio-discuss at openjdk.java.net
Subject: Re: NIO.2 and GC activity

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.