Another thing to consider when evaluating object pooling is the expected lifetime of the objects. On modern JVMs with generational memory stores, objects with a short lifespan (say the duration of a single HTTP request) will probably never leave the nursery. Pooling these kinds of objects usually degrades performance rather than improving it.
I've just finished some performance research on Tomcat 3.2 (I know, I know...) and one of the things I found was that the o.a.u.MimeHeaders and related classes were a huge performance bottleneck. The existing code went to great lengths to avoid creating 'garbage' and the result was code that was very slow. I replaced it with a much simpler set of classes that basically ignored the GC impact and saw a 15% performance improvement under load.
I find that *really* odd. We're not talking about an object pool here with the MessageBytes and the others, but rather a thread local direct reference. The code in utils seems very efficient to me, and even the worst JIT should look good tuning the array based algorithm of the HTTP/1.1 for your CPU.
Using and manipulating Strings and stuff instead of that is dead slow in comparison.
I confirmed with tests, as well as OptimizeIt (I don't know how real and accurate the OptimizeIt numbers are).
I can't be so affirmative when it comes to real object pooling, such as tag pools. However, I believe that GC is a problem for scalability no matter how good the VM is on a large scale system. These kinds of pools can be very easily disabled or configured, so I don't see any problem.
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
