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
implementation.
WDYT?
[1]
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends,
http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html
- Object pooling considered harmful Daniel Fagerstrom
-
