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.

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.



Reply via email to