NIO.2 and GC activity

[Leon Finker]

I'm not familiar with any performance comparison between .NET and JAVA GC. I
personally experienced the issue in earlier versions of .NET (and even
latest versions when using original async result based API) so I can relate
there.

Logically it would make sense not to create something (in very large
quantities) that will be thrown away. It will only be needed if the
framework forces it on the developer as the only way to get the result back.
Even short lived objects must be processed by GC and therefore CPU time
consumed for this work instead of same CPU time given to the application's
work. It's not uncommon to have 10,000 and much more per second socket
operations done on a server. That would mean that many Future objects will
be created. It's also possible for some of these objects to be promoted from
young to old generation if things fall behind (depending on how developers
use the model). Since it's still early(?) days for NIO.2, it should be
possible to avoid these extra objects by simply extending the API to
accommodate.

-----Original Message-----
From: nio-discuss-bounces at openjdk.java.net
[mailto:nio-discuss-bounces at openjdk.java.net] On Behalf Of Mark Thornton
Sent: Saturday, January 17, 2009 4:40 AM
To: nio-discuss at openjdk.java.net
Subject: Re: NIO.2 and GC activity

Leon Finker wrote:
>
> 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.
>
How does the .NET garbage collector compare with those available now in 
Java? I have piles of old code that worked around inadequacies in older 
garbage collectors (e.g. stuff from the 1.1 era). Today I am frequently 
amazed at how good GC is at coping with huge amounts of garbage. So does 
Java need this kind of optimization?

Mark Thornton