As Craig already said, it's not good to generalize. The only way to find out, is to test. (And always be prepared that the result may change in the next release of the vm)
If the garbage collector works as you describe, it's "quite easy" to improve it in a way that it does the opposite of your conclusion: If the gc stores the object in generation buckets, and your pooled objects live long enough to be stored in the older generation they don't have to be copied which each run of the gc. This way you may win performance from pooling. Beside the performance, there may be other advantages of object pooling, like the reduction of memory defragmentation or the reduction of memory usage. I prefer to use pooled objects either for relative small number of long lived objects or for objects that are expensive to create, or immutable objects that consume some memory and are likely to be in use concurrently. In fact 'pooled objects' is sometimes an over technical phrase for things like the following: static final Integer cMinusOne = new Integer(-1); static final Integer cZero = new Integer(0); Or the usage of Boolean.TRUE instead of new Boolean(true) > -----Original Message----- > From: Will Hartung [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 03, 2003 11:42 PM > To: Tomcat Users List > Subject: Re: Object pooling (was: more about custam tag life cycle) > > > > From: "Erik Price" <[EMAIL PROTECTED]> > > Sent: Monday, February 03, 2003 2:16 PM > > Subject: Re: more about custam tag life cycle > > > > Are you saying that in general, object pooling is > deprecated? In other > > words, it's always a bad idea, with the exception of DataSource type > pools? > > As a design issue, Object Pooling is frowned upon with the > modern garbage > collectors because short lived objects are "cheap". One of > the original > goals of Object Pooling was to put less strain on the GC by > not creating > lots of short term objects. > > With modern collectors, this is much less of an issue. For > example, modern > collectors during a GC will copy active objects. So, your GC time is > relative to the number of active objects, rather than total allocated > objects. For example, if you have 1000 active objects, and > the GC will be > copying them, then by the time the GC happens, it's > essentially irrelevant > whether you have 100 inactive objects or 100000000 inactive > objects, your GC > time will be the same. > > Therefore, the modern GCs are, if anything, "punishing" you > for keeping > objects around, rather than punishing you for simply creating objects. > > So, that means that whereas before the expense of an object was its > creation, release, and GC, now the only expense is its > creation and release. > > Of course, object creation is not free so as a general > guideline it's better > to minimize object creation in general. However, using an > Object Pool is not > necessarily prudent for generic objects, as you will be "punished" for > saving them. > > Now, for objects that are especially expensive in their > creation and are > also inherently reusable, then pooling makes sense (and DB > connections fall > well into this category). > > All that being said, it does not mean the pooling within, > say, a JSP code > generator is necessarily bad. It can make the code a wee bit easier to > create, as you simply surround Tag use (in this case) with > "getOrCreateTagFromPool" and "placeTagBackInPool". This puts > the burden of > tracking used Tags and what not upon the JSP runtime, rather than the > compiler. > > This is not a big deal in this case because the Object Pool > could have a > short life span and probably won't survive a GC. > > Anyway, in summary, as a general rule Object Pools are more > expensive than > they are worth with modern GCs. However, with a better > understanding of > them, you may find scenarios where they are worth utilizing. > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
