From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Found a very interesting read at http://www-106.ibm.com/developerworks/library/j-jtp01274.html?
ca=drs-j0504
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:
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessio ns/pdfs/1522.pdf
+ 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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
