[concurrency-interest] Re: PooledLinkedBlockingQueue

Larry Riedel larryr@saturn.sdsu.edu
2 Nov 2004 02:34:56 -0000

> > 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'd really like for Sun to put a counting GC on the list
> of GC implementations.

I think it would be great if developers could explicitly manage
object lifecycles and memory allocation, tell the garbage
collector to find all unreachable objects, to run finalizers,
and be able to resurrect the unreachable objects; and to be able
to create objects with associated garbage collection policies,
and to have pluggable garbage collectors which use a standard
garbage collection API/SPI (and corresponding object metadata).

> > there is nothing about objects which are pooled/cached
> > rather than created/destroyed [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.

I think it is particularly lame to have to create/destroy an
object for every time the pooled object is put/taken, when a
mechanism for avoiding that (WeakReference/ReferenceQueue) is
already in the JVM and just lacks a ReRegisterForFinalize()
(CLR) style method.  But I would not object to the idea of
having a pool specific object for each pooled object, one which
has the same lifetime as the pooled object, but has (for
example) a finalizer so the pooled object does not have to.