cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Alternatives to Poolable
Date Tue, 10 Feb 2004 11:16:00 GMT
Leo Sutic wrote:

>>From: Sylvain Wallez [] 
>>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.
>Yes, but he links to a presentation from JavaONE, that summarizes
>pooling with:
> + Loses for light-weight objects
> + A wash for mid-weight objects (Hashtables)
> + A win for big objects.
>Basically - if your object is significantly bigger than a Hashtable,
>you should pool it.
>What it boils down to is this: Is the time it takes to bring the object
>out of the pool (with the associated synchronization costs) longer
>than it takes to re-create the object?
>For Cocoon, I'm not sure that's the case. I think most objects
>in Cocoon are "big" by the definition given above.

Are they intrinsically big, or are they big because of all the stuff 
every instance must hold that could be delegated to the "component 
fields" I suggested?

I think most components fall in that second category.

Furthermore, pipeline components are stateful because of the 
asynchronous nature of SAX, but that state doesn't survive past the 
processing of a pipeline: the state is initialized on startDocument() 
and trashed on endDocument(). Hence the possibility to change these 
components into factories.


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

View raw message