avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Sun, 09 Jun 2002 01:15:01 GMT
Hi Robert,

> From: Robert Mouat [mailto:robert@mouat.net]
> 
> On Sat, 8 Jun 2002, Leo Sutic wrote:
> 
> > > From: Robert Mouat [mailto:robert@mouat.net]
> > >
> > > - relies on the VM's GC to return the component to the pool,
> > > and it is unclear how long this will take.
> > -1 for that reason.
> 
> The CM's lookup/release pair remind me a lot of the new/delete pair --
> which we don't have in Java because the VM does the 'delete' for us.
> 
> If it is ok to let the VM reclaim memory assigned to objects without
> having much control over the process, why is there a problem applying
this
> approach to reclaiming components for a pool?

You could buy 2Gb RAM and it won't cost a fortune, but you may fail to
buy enough licenses to create so many (licensed) components to fill
these 2Gb.

Same argument may apply to pool of any other components which utilize
some hardware resources which are more limited than memory (say, sockets
- you have just ~65536 of them (never counted them...)).

Java GC kicks in when memory is low; Pool GC must kick in when pool is
low. Can you control this efficiently enough to remove release method?


> couldn't the same arguments work in each case?

I'm not sure because of argument above.

Vadim


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message