On Jul 27, 2006, at 23:56, Andreas L Delmelle wrote:
<snip />
I wouldn't be surprised to see a lot of these trees occur in the
course of the process, but if I esteem correctly, in a literal
snapshot, there should be only one. There is only one handler which
has one reference to the current block. That reference is never
explicitly cleared, but strictly speaking, it never needs to be
since it is re-used. Taking a snapshot right after FOP has
finished, would reveal the last one, provided that the reference
tree Root->AreaTreeHandler->XMLWhiteSpaceHandler has not yet been
completely cleared/released.
Was re-thinking this particular phrasing, and had a closer look...
Moved it to fop-dev, because of the importance.
Firstly, this looks like a damned circular reference, indeed! That's
my bad, sorry.
Since the reference to the last block is not released unless the
reference to the Root's AreaTreeHandler is cleared, this keeps the
entire ancestry alive, up to the PageSequence, which itself holds a
reference to the Root? :| ... :(
Definitely worth a try to release the reference XMLWhiteSpaceHandler-
>Block as soon as possible.
OTOH, looking deeper, I'm strangely surprised no-one saw this one
before --so surprised even that it makes me think I'm missing
something :
Root.addChildNode(PageSequence) results in a reference to the
PageSequence being kept in the Root's list of child nodes. Right?
AFAICT, this reference is *never* released as long as the Root object
is alive, so it seems like currently, our 'split up in page-
sequences' performance hint is complete and utter bogus...?
Sorry to disappoint you all.
Good news is, both are rather easily fixed --at least on the surface.
Either:
a) override addChildNode() in Root, so that the PageSequences don't
get added to the List at all; maybe only under certain circumstances
(unresolved forward references?) should this be needed
b) call Root.removeChild(this) in PageSequence.endOfNode()
c) call Root.removeChild() from the next PageSequence's startOfNode()
Unfortunately, I am a bit stuck in the marker-property rework ATM --
FOText in a marker turns out to be a little bit more difficult than
the FObj-subclasses... Decided to take care of the dubious static
FOText.lastFOTextProcessed in one go, so that will make a nice set of
improvements 8)
I'll make it a priority to clear this up after that, if nobody beats
me to it.
Cheers,
Andreas
