cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject [RT] Alternatives to Poolable
Date Tue, 10 Feb 2004 10:30:49 GMT
Found a very interesting read at

This articles explains the memory allocation and collection strategies 
of modern JVM and show that object recycling and pooling can cause more 
harm than good.

I've always been worried by the fact that most of our stateful 
components are Poolable (stateless ones are ThreadSafe) and not simply 

We make them Poolable because their creation cost is high. But why so? 
Because the Avalon framework brings a lot of overhead to object creation 
by going through the various lifecycle interface, and because each of 
the created instances has to perform repetitive actions that could be 
shared between the various instances. The main cost in this area is 
parsing the configuration, which is the same for all instances of a 
given component.

This leads to identifying something I would call "component fields" 
which are between static fields (system-wide values for a class - 
identical for the various component declarations using a class) and 
instance fields (specific to a given instance).

How can we solve this? I see two solutions:
- define a new lifestyle that would ask the container to hold those 
"component fields", and have them computed once at startup by one 
instance of the component class. This strategy is similar to 
- avoid stateful component definitions everywhere it is possible. For 
example (I already talked about this), the Transformer interface, 
instead of being an XMLPipe (and thus a ContentHandler), could be a 
factory with a single method "getContentHandler" method.

These approaches can allow to remove most of the object pools that are 
the most difficult point in tuning Cocoon for performance.

The first idea complexifies the contract between components and the 
framework, which may not be a good idea (see [1] and [2] for very 
interesting reads on this subject) whereas the second approach requires 
some deep changes to what we have today.

These are random thoughts, but WDYT?



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message