NIO.2 and GC activity

[Leon Finker]

I realized after I sent previous email maybe this is not cross platform so
it 
may not be feasible. It is fully supported on windows. Yes I'm referring to 
buffer(s) always being available to the driver. The goal is to try and
saturate 
driver with outstanding read buffers (to a limit of course) to minimize any 
buffering on its side. The buffering in driver will in most cases happen
while 
NIO.2 hands off the read buffer and application does some simplistic
processing 
on it. With more than one outstanding read buffer, this can be minimized.
Instead 
of driver waiting for application to schedule another read while one
completed, 
driver can fill in previous outstanding read buffers and fire completion.
The only 
issue in this case is to deal with out of sequence read completions. As long
as 
simultaneously outstanding read buffers are always kept within a certain
maximum, 
it works to our advantage.

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

Leon Finker wrote:
> 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.
>   
Just so we're clear, you can initiate another read operation in your 
completion handler (it doesn't t require the completion handler to 
complete). The optimization that I think you are referring to just 
requires that there is a buffer available for an outstanding read so 
that it can read directly into the buffer. That should work fine and 
only rarely (protocol dependent and buffer size dependent of course) 
should the driver need to buffer.

-Alan.