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.