Hi Andreas,

Just a small comment as I’m far from being an expert in this whole
area...

> The following page has been changed by AndreasDelmelle:
> http://wiki.apache.org/xmlgraphics-fop/PropertyHandling/PropertyCache
>
> ------------------------------------------------------------------------------
>
> + In its most basic form, some {{{Property}}} subclasses that did not
> require a layout context for resolution were equipped with a private
> static {{{WeakHashMap}}} that retained all created instances to which
> other objects held hard references, and accompanying implementations
> for {{{equals()}}} and {{{hashCode()}}}. Their constructors were made
> inaccessible from outside the package, and instead new instances were
> created via a public static {{{getInstance()}}} method. That method
> creates a new instance, performs a {{{get()}}} on the {{{HashMap}}},
> adds it if it does not exist yet, and returns either the result of the
> {{{get()}}} or the newly created instance.
> +
> + Since all the related constructors are simple parameter assignment 
> constructors, like:
> +
> + {{{
> + public MyProperty(int someInt, Object someObj) {
> +     this.primitiveValue = someInt;
> +     this.referenceValue = someObj;
> + }
> + }}}
> +
> + and the generated instances only have to be moved from the stack to the 
> heap if they are really ''new'' instances to be added to the map, the 
> involved overhead should be minimal in a language like
Java, especially with modern VMs. The well-known warning about instantiation 
rates in the early days now more apply to circumstances where one would trigger 
a chain of constructors with every
instantion (e.g. if the second assignment would be {{{this.referenceValue = new 
OtherClass();}}}).

To my knowledge an object is always created in the heap, never on the
stack. The PropertyCache is efficient not because it avoids to move
instances to the heap, but because references to newly created instances
are immediately released, which makes them immediate candidates for
garbage collection; instead of having numerous physically different
instances in memory, all of them being logically equivalent.
Does that make sense?

<snip/>

Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to