[concurrency-interest] Re: PooledLinkedBlockingQueue

Gregg Wonderly gregg.wonderly@pobox.com
Mon, 01 Nov 2004 19:23:41 -0600

Larry Riedel wrote:
> As an application developer, I generally prefer to have
> the garbage collector track object references, rather than
> requiring the application code to do it; that is why I
> want garbage collection-- to relieve the application code
> of the burden of tracking object references;

I can see this both ways.  Often, I want to control certain things about 
the lifecycle of the objects in the system.  Typically, I know more 
about whether something is ready to be reclaimed than I want the GC to 
implicitly discover.  I want it to spend less time using the CPU to 
discover things in O(N) time that I can tell it in O(1).  Especially for 
large counts of objects.  This is why I'd really like for Sun to put a 
counting GC on the list of GC implementations.  Mark-and-Sweep is nice, 
but not great for very large, very active collections, without a whole, 
whole, whole bunch of code that can have more bugs than you can shake a 
stick at.

 > and there is
> nothing about objects which are pooled/cached rather than
> created/destroyed which fundamentally changes this for me--
> leads me to think users of objects which happen to have come
> from a pool should even have to know if the objects they use
> are pooled/cached vs created/destroyed.

I am not saying they need to know this explicitly.  I think it would be 
better to have a facade object that would manage the removeal from the 
pool in its constructor and return the object to the pool in its 
destructor.  This would let you plug in different strategies in 
different circumstances, without having to replace the Object that 
everyone is creating.