Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
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: + All the related constructors are simple parameter assignment constructors, like: {{{ public MyProperty(int someInt, Object someObj) { @@ -39, +39 @@ } }}} - 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();}}}). + and the generated instances are short-lived. so they only have to be moved in the heap (for Sun JVMs, 'out of eden': see http://java.sun.com/docs/hotspot/gc1.4.2/#2.%20Generations|outline) if they are really ''new'' instances to be added to the map. As a consequence, 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();}}}), and the !OtherClass constructor might again trigger construction of a new object (which would increase the size of the ''young'' generation, and possibly cause relocations of instances in the heap). As the number of objects to which this approach was applied, began to grow, the decision was made to implement a dedicated class that could be used by any of the {{{Property}}} classes. The concern for multi-session environments was first taken into account by wrapping the {{{WeakHashMap}}} in a standard synchronized map. The {{{PropertyCache}}} itself would only have one or more {{{fetch(Object obj)}}} methods as public access points, that took care of the operations that were initially performed within the {{{Property}}} subclasses (see above), so the idiom had become simply: --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
