NIO.2 and GC activity

[Leon Finker]

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. 

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. 

-----Original Message-----
From: nio-dev-bounces at openjdk.java.net
[mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman
Sent: Tuesday, April 14, 2009 11:32 AM
To: John Franey
Cc: nio-dev at openjdk.java.net
Subject: Re: NIO.2 and GC activity

>Changing the methods that have a completion handler as parameter to 
>return void is probably the right thing to do. However,  as I said in a 
>previous reply, this doesn't eliminate all object allocation as there are 
>still cases where some objects are required (timers for example). A 
>while back I did a number of tests but didn't observe any noticeable 
>difference because the scavenging of the new generation was so fast.
...