avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Mouat <rob...@mouat.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Sat, 08 Jun 2002 18:11:17 GMT
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?

couldn't the same arguments work in each case?

> >  [I don't know 
> > much about GC implementations, but theoretically if there are 
> > no circular references the reference count could become 0 and 
> > the VM could remove the object immediately]
> Yes, but then we are making assumptions at how GC is implemented 
> in VMs. It is perfectly legal for a VM to not GC until it has filled
> the heap completely. So if you start with a heap of 5MB and has a
> heap max of 2GB, GC may not kick in until you have reached that upper
> limit.

so, the better the VM the better the performance... :)

If the only reason for using pools is performance then some tuning is to
be expected whenever they are used (e.g. determining the pool size).  
This tuning is going to be dependent on implementation (e.g. different
implementations will require different pool sizes for best performance).

Is there a reason to expect a significant performance difference between a
pool tuned for an explicit release(), and a pool tuned for using the VM's
garbage collection to do the release?

I'll admit that with a explicit release() it might be possible to tune a
pool for use with all VMs, while a GC release() will potentially need to
be tuned for each VM -- but isn't it reasonable to expect the
administrator/deployer of an application to perform some tuning to suit
their environment (especially if they are concerned about performance).

finally, if a pool runs out of components there is nothing stopping it
from running the garbage collector itself [though again, this would need
tuning -- but might make reduce the differences between VMs].


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

View raw message