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...?
Cheers,
Andreas
