[concurrency-interest] PooledLinkedBlockingQueue

Adam Messinger adam@bea.com
Wed, 3 Nov 2004 11:00:30 -0800

On Nov 3, 2004, at 6:54 AM, Doug Lea wrote:

> Right. I continue to doubt that you can outperform the current
> GC-based approach using ThreadLocals in most applications.

We've looked at this issue extensively when doing performance work on 
the WebLogic Server.  We've measured pooling in a variety of use cases, 
with a variety of pooling implementations, and on a variety of hardware 
and VMs.  What we've found empirically is that Doug is exactly right.

In addition to the costs Doug mentions in his email you must also 
consider that each pool causes additional drag on GC by occupying 
memory and thus causing GC to happen more frequently.  By dedicating 
pools of memory to specific uses some object types are essentially 
receiving a higher priority for memory use, in general I think that 
this will lead to a less globally optimal use of memory.  In addition, 
most modern VMs use a GC algorithm which has cost roughly proportional 
to the number of live objects.  Therefore keeping unused objects around 
in pools causes the GC to do more work.

> There are other scenarios where it could go the other way, but I think 
> this one is the most typical.

As Doug states there are some scenarios where pooling does help and in 
those cases we do use it inside the WebLogic Server, despite its higher 
cost of maintenance.  The two general categories where we've found 
pooling to be useful are objects which are too big to be allocated from 
the thread local area and objects which have very expensive 
constructors.  Therefore I don't think that small bucket objects of the 
type being described here, which are quite small and have very cheap 
constructors, are a good candidates for pooling.