NIO.2 and GC activity

Leon Finker leonfin at optonline.net
Tue Apr 14 11:06:42 PDT 2009


This can be optional. Current enforced requirement removes possible
optimizations for receive that developers can do. I worked on communication
layer that did benefit from multiple outstanding recvs. I don't have all the
reference available, but here is one I could find quickly
http://msdn.microsoft.com/en-us/magazine/cc302334.aspx
"as long as the application takes care to always have a few overlapped
WSARecvs outstanding on a connection. The availability of posted application
buffers removes the need for AFD to buffer incoming data."

In short more than one receive can be an optimization where data will not be
buffered in tcp stack, but written directly to application buffer (more
optimizations in win2k8 and up including NIC writing directly to memory
where application buffer is http://support.microsoft.com/kb/951037). So what
if one has to deal with not so complicated re-sequencing logic? The core of
communication layer code is written and tested once. It doesn't change
often. I personally vote against this enforcement. It can be enabled for
debug or made optional.

-----Original Message-----
From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] 
Sent: Tuesday, April 14, 2009 1:32 PM
To: Leon Finker
Cc: nio-dev at openjdk.java.net
Subject: Re: NIO.2 and GC activity

> In addition the recommended way (at least on windows iocp) is to have more
> than one outstanding socket operation pending per socket (btw does NIO.2
> allow for this? To have more than one asynchronous pending socket receives
> for example). This increases the number of objects that will get promoted
> per connection per socket operation. I didn't do any stress testing yet
> myself. 
>   
For stream based protocols you don't want to have several read 
operations outstanding on the same channel. No problem for datagram 
based protocols. The API does enforces this (in 
AsynchronousSocketChannel) for stream protocols. This has already helped 
several people to find bugs that would otherwise have caused bytes to be 
read or written out of order.

-Alan.




More information about the nio-dev mailing list