There are several reasons to use pooling, including (but not limited to): -Eliminating object creation time -Managing expensive resources (really same as first) -Keeping memory usage constant (popular in embedded environments) -Reducing garbage collection
Only the last one is addressed by the quotes below. And is especially visible in cases where a program may create, for example, 5000 Rectangle objects and then manage the pool as needed. The current GCs will be much better at managing these objects than a pool would. Tomcat benefits from all of the above reasons, but from a performance perspective, probably mostly from the first two. (Costin's analysis in the other response seems to bear proof of this.) -Paul Samuel Cheung wrote: > > Hi, > > In TomCat's source code, I notice it recycles objects (e.g. RequestBase, > StandardSession). But in Sun's documentation, with HotSpot Virtual machine, > pooling objects will hinder performance (see below). Could someone please > tell me are there advantages of using object pooling in TomCat? > > Thank you. > > Sam > > <<<<< From Sun's Web Page. > http://java.sun.com/docs/hotspot/PerformanceFAQ.html#15 >>>>>>>> > Should I pool objects to help GC? Should I call System.gc() periodically? > Should I warm up my loops first so that Hotspot will compile them? > > The answer to all of these is No! > > Pooling objects will cause them to live longer than necessary. The garbage > collection methods will be much more efficient if you let it do the memory > management. We strongly advise taking out object pools. > > Don't call System.gc(), HotSpot will make the determination of when its > appropriate and will generally do a much better job. If you are having > problems with the pause times for garbage collection or it taking too long, > then see the pause time question above. > > Warming up loops for HotSpot is not necessary. HotSpot now contains On Stack > Replacement technology which will compile a running (interpreted) method and > replace it while it is still running in a loop. No need to waste your > applications time warming up seemingly infinite (or very long running) loops > in order to get better application performance. > > See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
