[concurrency-interest] Re: PooledLinkedBlockingQueue
Mon, 1 Nov 2004 10:21:56 -0800
I'm not sure I fully understand this discussion. In general,
finalization (or any flavor of weak reference) tends to be
significantly more expensive for the garbage collector to
manage than just memory reclammation. (The GC really
runs the finalize method only if an object has a nonempty one,
which is known at allocation time.) 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.
Aside from that, I agree that not being able to reenable finalization
on an object is an odd restriction. But I'm not sure it has much
to do with this group.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org]On Behalf Of Larry
> Sent: Sunday, October 31, 2004 4:45 PM
> To: email@example.com
> Subject: [concurrency-interest] Re: PooledLinkedBlockingQueue
> > > I am worried that the pool become a bottleneck
> > > with synchronization. So, is-it possible to
> > > don't do any locking when using the pool? Is the
> > > wait-free ConcurrentLinkedQueue a good choice?
> > This is the reason that performance of GC'ed
> > concurrent data structures tends to be better than
> > those using recycling.
> 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.
> Concurrency-interest mailing list