Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Message-Id: <200302181917.h1IJHbN30737@gandalf.savarese.org>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: StringBuffer pools and why not to use them 
In-reply-to: Your message of "Tue, 18 Feb 2003 10:19:40 EST."
             <0C072E7CC947D511AC9600A0CC734120885E2B@XEON400>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Feb 2003 14:17:37 -0500
From: "Daniel F. Savarese" <dfs@savarese.org>


In message <0C072E7CC947D511AC9600A0CC734120885E2B@XEON400>, Lester Ward writes
:
>I was doing some performance tuning recently and thought to try pooling
>StringBuffers. I built a pool for them based on StackKeydObjectPool. Bad
>idea. Here is why:

A number of Java performance rules of thumb seem to have been invalidated
by the latest HotSpot releases.  I can't give you the exact reference
off the top of my head, but the HotSpot team actually recommends that
programmers avoid object pools altogether now and to trust the memory
allocation and garbage collection system to perform efficiently.  Your
experiment appears to support this recommendation.  I have not taken
the time to investigate the situation in detail, but my general impression
is that pooling objects simply to avoid the cost of memory allocation may
well not be a win in many cases with the HotSpot runtime that accompanied
J2SE 1.4.  However, pooling objects whose creation or initialization incur
additional costs beyond simple memory allocation--such as database
connections, threads, and network connections--is still a major win.
There is also evidence that pooling simply to avoid the cost of memory
allocation provides major benefits in programs that use many threads
running on multiple processors.  The memory allocation system is serialized
(or at least it was; I vaguely recall plans to parallelize it), which
creates a major bottleneck in concurrent programs.  Pooling sidesteps
this problem.

The real performance benefits of the changes introduced in the latest
versions of the HotSpot runtime (it's not just a JIT) are still poorly
understood, so you have to test things out to gauge the efficacy of
optimization techniques that used to be no-brainers.

daniel