commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durham David Cntr 805CSS/SCBE" <>
Subject RE: StringBuffer pools and why not to use them
Date Tue, 18 Feb 2003 19:54:18 GMT
Very similar to the .clone() guidelines.

> -----Original Message-----
> From: Daniel F. Savarese []
> Sent: Tuesday, February 18, 2003 1:18 PM
> To: Jakarta Commons Users List
> Subject: Re: StringBuffer pools and why not to use them 
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message