tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Hartung" <>
Subject Re: Object pooling (was: more about custam tag life cycle)
Date Mon, 03 Feb 2003 22:41:47 GMT
> From: "Erik Price" <>
> 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

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

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.


Will Hartung

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message