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.
http://svn.apache.org/viewvc?rev=428450&view=rev 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
