NIO.2 and GC activity

[Rob Butler]

Speaking as someone who builds big server applications, GC is usually our biggest problem.  Anything that can be done to reduce GC pressure is worth at least looking into.  

Also, considering that in most cases the future isn't used and is immediately thrown away why bother creating it in the first place.  Perhaps another way to solve the same problem is have two methods.

Future read(...)

void readNoFuture(...)

This would be backwards compatible with the existing API.  But I'd prefer

void read(...)
Future readFuture(...)

These won't reduce GC when you need to use Future, but in most cases where it isn't needed you save a useless object creation. (Perhaps thousands per second.)

Rob

----- Original Message ----
> From: Mark Thornton <mthornton at optrak.co.uk>
> To: nio-discuss at openjdk.java.net
> Sent: Saturday, January 17, 2009 4:39:40 AM
> 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:
> > 
> > Futureread(ByteBuffer dst, … CompletionHandler
> 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