NIO.2 and GC activity

Leon Finker leonfin at optonline.net
Fri Jan 16 10:09:31 PST 2009


Hi,

 

I would like to provide feedback on NIO.2 based on the specs, and what I've
been reading about the implementation. 

 

1.

I'm drawing from .Net experience here. We have encountered a bottleneck with
earlier .NET networking implementations,

 and I feel that NIO.2 is heading in the same direction. Please correct me
if I'm wrong. 

 

Proposed NIO.2:

Future<Integer> read(ByteBuffer dst, . CompletionHandler<Integer,? super A>
handler)

etc.

 

Earlier versions of .NET: 

IAsyncResult BeginReceive(byte[] buffer, ., AsyncCallback callback, .)

 

The problem is that too many temporary Future/IAsyncResult objects are
created and thrown away without ability to pool them, 

which puts unnecessary stress on the GC. Recent versions of .NET came out
with new much more optimal socket API which eliminates 

all the temporary object creations and therefore consuming minimum CPU due
to GC activity:

 

bool ReceiveAsync(SocketAsyncEventArgs e) and SocketAsyncEventArgs exposes
the Completed event for notification of the operation. 

 

This allows one to pool SocketAsyncEventArgs, those eliminating the
temporary object creations. It doesn't really matter how it's done. I just 

brought the example since it already exists in another framework. 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. 

 

2. Is NIO.2 on windows based on IOCP?

 

Thank you

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090116/57f49ef5/attachment.html 


More information about the nio-discuss mailing list