Am Di, den 10.02.2004 schrieb Sylvain Wallez um 11:30: > 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.
I was on a developer session during a Sun Network conference over GC and object pools. The session clearly shows that the GC itself managed pools the objects. And only heavy objects should be pooled like Connections. So the pools of avalon are more harmful, IHMO. > I've always been worried by the fact that most of our stateful > components are Poolable (stateless ones are ThreadSafe) and not simply > SingleThreaded. > > 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). I think the container should only work as factory, create a new object for every lookup, except for threadsafe components. The configuration objects can be reused. Heavy objects can be stored the "Store". And the release() methods can be droped. For example in my application, at Im working on, I can create 5000 objects in 2ms. To find out in an object exists, and if it can reused etc, will cost much more than 2ms. So, +1 from my side. Stephan.
