[concurrency-interest] Re: PooledLinkedBlockingQueue
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.