On Jun 14, 2006, at 19:16, Simon Pepping wrote:

Hi Simon,

On Mon, Jun 12, 2006 at 07:36:34PM +0200, Andreas L Delmelle wrote:
On Jun 12, 2006, at 15:29, Simon Pepping wrote:

There may be problems with the property lists of the Marker children,
which are currently not cloned, but referred to in descPlists. The
property lists of a subtree of a marker are special, because they must
be kept alive for later retrieval. Other property lists are garbage
collected after the properties have been bound to the LM and the
subtree of the FO has been processed.

Not all, unfortunately. See the comment in RetrieveMarker about using
StaticPropertyList (which stores a reference to its
parentPropertyList, which also happens to be a StaticPropertyList
etc. until the PropertyList for the fo:root) :/

Fortunately. That is the other side of the coin. The property lists in
the ancestry of a retrieve-marker also need to be protected from
garbage collection, in order to be able to resolve properties after
retrieval of a marker.

Well, maybe I was thinking too much in terms of memory that is occupied too long. StaticPropertyList is, as its javadoc explains, an ultra-fast array based implementation that eats substantially more memory than an instance of its superclass... hence the idea of MarkerPropertyList, I'd say.

In case of retrieve-markers, the consequences are less drastic, because they generally appear not too deeply nested, but still... The cases where a property list holds values for more than 20-30 percent of all possible properties are extremely rare (which means that for the other 70-80%, bytes are allocated for the reference but never occupied (=always null) --which makes it even more of a waste). I'm not 100% sure, but I would say that this was Finn's key motivation behind binding the properties to instance variables of the FObjs.

We could resolve inheritance up to the retrieve-marker at parse-time, and build a special PropertyList which 'merges/flattens/collapses' -- can't seem to find the right word-- the lists of the ancestors. We'd only need to make sure to override methods like getInherited() to not go looking for a parentPropertyList, but simply return the value from that special PropertyList attached to the RetrieveMarker.

Inheritance for properties specified on the marker-descendants obviously has to wait until the layout-phase.

Then again, maybe I'm seeing things too simplistic and those (4 bytes per reference * some 250 properties * the number of StaticPropertyLists) don't mean all that much...?



Reply via email to