cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Object pooling considered harmful
Date Tue, 02 Jan 2007 22:05:22 GMT
One complication in our work in making the Cocoon components work in a 
standard Spring container without special Avalon support is that a large 
amount of our components are Poolable (or more specifically Recyclable). 
And Spring doesn't have any concept of object pooling.

Even worse Spring doesn't even have a concept of returning components to 
the container. For singletons the container can call a destroy method 
when the component goes out of scope. But for non singletons 
(prototypes) your are on your own and have to take care of destroying 
the component yourself. Of course it is possible to implement pooling 
for Spring anyway, but Spring doesn't help us.

                  --- o0o ---

So I started to search the web to find out if anyone else had done some 
work on extending Spring with object pooling support. And found nothing. 
But what I did found were some articles that explained, rather 
convincingly, that object pooling will decrease rather than increase 
performance in most cases [1].

What is this object pooling about? Once, long time ago, Java was really 
slow in creating and destroying objects (it was actually slow in doing 
about anything). So one optimization trick was to keep a pool of objects 
and clean them and reuse them instead of destroying them and creating 
new ones. In Cocoon this is done for nearly all sitemap components.

Now with modern JVMs (1.2 and later), things has changed dramatically. 
Creation and destruction of objects is amazingly fast. A "new Object()" 
is about 10 machine instructions in HotSpot 1.4.2 and later, while the 
best performing malloc in C requires 60-100 machine instructions [1].

And for short lived object, like most sitemap components that only has 
request scope, destruction has most often zero cost.

For pooled object OTH, their object graphs must be traversed by the GC. 
They also bulk up memory and might create synchronization bottle necks 
for the object pools. Handling pooling is also rather intrusive in the 
code as one have to keep track on the recycling everywhere.

The conclusion in [1] is that object pooling today only is worthwhile 
for small object that are very expensive to create. Taking a look on 
what kind of objects that are recycled in Cocoon core all components 
that I found are really simple to create. Most objects just have a 
number of fields that are nulled in the recycle method. For these 
objects already the recycle method might be more expensive than 
destruction + creation. The most "heavy" components also contains a few 
array lists or hash maps that are cleared in the recycle method. That is 
about it.

                  --- o0o ---

My proposal is that we don't bother trying to implement object pooling 
for POJOfied Cocoon components, we should use prototype scope instead in 
Spring. Actually I would go even further and suggest that we just turn 
off recycling in the Avalon-Spring adapter and treat Poolables as 
prototypes. I also suggest that we deprecate all recycle methods in our 
abstract base classes for sitemap components.

This will AFAICS, booth improve Cocoons performance and simplify the 



View raw message