Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <459B96C9.4080907@apache.org>
Date: Wed, 03 Jan 2007 12:43:05 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Object pooling considered harmful
References: <459AD722.6090304@nada.kth.se>
In-Reply-To: <459AD722.6090304@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I totally agree that we should avoid object pooling and should in no way
introduce this for beans.
We have a working pooling implementation for the Avalon components which
is transparent (and therefore much better than the original excalibur
implementation we use in 2.1.x) and I don't see a need for removing this.
As soon as we have moved most of our Avalon components to beans, we
could think about removing pooling for Avalon components. So what about
deprecating this in 2.2 and removing it with 2.3 or 2.4?
Btw, removing the support for pooled Avalon components might create
memory problems as currently resources are freed in the recycle() method.

Carsten

Daniel Fagerstrom wrote:
> 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
> 
> 


-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/