NIO.2 and GC activity

[Alan Bateman]

Leon Finker wrote:
> But creating objects (i.e. timers) is current implementation detail.
> Implementation can change to not create objects per request. Implementation
> can allow objects to be reused. 
>
> When you are talking about new generation scavenging are you only referring
> to actively streaming connections where flow of data is never delayed?
> Object will be promoted as soon as data availability is delayed (whatever
> the reason will be). With thousands of connections this has to cause a
> delay. 
>   
Right, as I said in the original reply, the real concern is where the 
objects survive just long enough to be promoted.

> 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.