RE: Object pooling (was: more about custam tag life cycle)
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 1 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]
RE: Object pooling (was: more about custam tag life cycle)
On Tue, 2003-02-04 at 00:34, Ralph Einfeldt wrote: 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. Pooling is actually a great thing to do with immutable objects. The object is immutable, so it is in a correct state from construction to garbage collection. Also, because it is immutable, it can be shared by multiple threads and other objects. That's great. If tags were immutable, then pooling might be a very cool feature. Unfortunately, tags have the worst of both worlds: they are mutable, and they are pooled. This means they are difficult to use correctly because they are trying to work like C++ things instead of like Java things. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Object pooling (was: more about custam tag life cycle)
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. And what you think about objects that are created millions of times and pratically do not change any of its properties? I have some objects that deal with database queries (I store my SQL queries in a XML file... long story), so I have one of these objects created for each query executed in my database... I was thinking about pooling these guys, but I'm not sure. -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303341 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 1 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]
Re: Object pooling (was: more about custam tag life cycle)
Will Hartung wrote: 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. Thanks. Someday I will have to learn more about garbage collection. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
