I went looking and found that the fix is actually very easy: Just make
sure a page-sequences FO children are unreferenced when a page-sequence
is done. The PageSequenceLM is properly disposed by the AreaTreeHandler
so at least the LMs were already released properly. So far I haven't
seen any negative side-effects (like NPEs) from that change. Let's keep
a eye on it, though.


On 28.07.2006 22:41:52 Andreas L Delmelle wrote:
> On Jul 28, 2006, at 21:21, Simon Pepping wrote:
> > <snip />
> > IMHO we create a number of circular references in our trees. I have
> > always feared that we do not clean them up well enough. Are there
> > tools to investigate this?
> In itself a circular reference is not necessarily a problem, I think.  
> As long as the circle gets broken at some point, the allocated heap  
> space will eventually be reclaimed. It's only a matter of _when_ this  
> becomes possible. Currently, it looks like the whole reference tree  
> for all FObjs in all PageSequences is cleared only when the whole  
> document is finished.
> In the case of the XMLWhiteSpaceHandler, the reference to the current  
> Block seems to be kept alive slightly too long. The reference is only  
> cleared when replaced by the first block in the next sequence. To  
> allow optimal GC, I think this should be released sooner --end of the  
> page-sequence at the latest. But this would only make a difference if  
> all other references to the PageSequence are also cleared, of  
> course... If not, then the Block is referenced until end-of-document  
> anyway.
> I have not yet inspected the layout-tree, but I assume a similar  
> problem is impossible there, as the PageSequenceLM is at the root of  
> each LM-tree. The LM points to its FObj, and not the other way round,  
> so all seems OK.
> Cheers,
> Andreas

Jeremias Maerki

Reply via email to