[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-user
Subject:    Memory leak? (was: 'Possible' memory leak on fop-users)
From:       Andreas L Delmelle <a_l.delmelle () pandora ! be>
Date:       2006-07-27 22:44:00
Message-ID: 9686EAF1-476B-4A15-A1DD-1AAC78FF4366 () pandora ! be
[Download RAW message or body]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]