[concurrency-interest] Re: PooledLinkedBlockingQueue

Gregg Wonderly gregg.wonderly@pobox.com
Mon, 01 Nov 2004 13:52:22 -0600

Boehm, Hans wrote:
> The idea of maintaining
> a separate free memory pool based on the finalizer mechanism
> doesn't strike me as having much of a chance of profitability,
> unless the objects in the pool are extremely expensive to reconstruct.

>>What bothers me is that with the JVM I am only allowed to
>>resurrect an object once, so I cannot let the garbage
>>collector tell me when an object is not reachable so I can
>>put it back in the pool.   Unless this changed in JDK 1.5.

The issue with the GC is exactly this.  It is expensive to run a 
finalizer.  It's also expensive to assert synchronization arbitrarily.

It seems that if objects are expensive enough to create that you want to 
preserve them, then you should be using a factory creation and disposal 
mechanism that allows you to manage the lifecycle explicitly.  The close 
method on I/O objects is an example of something that's never been 
lumped into finalization.

If it's expensive to adapt existing code to do this, then you've really 
got a different issue about design and where you are at in the lifecycle 
of the architecture.  You should deprecate the constructors and provide 
the factory creation method/class.  Then, optimize for the new uses.

If it's still too expensive and too tedious, then it may be time for a 
completely different architecture.