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

List:       fop-user
Subject:    Re: Possible memory leak
From:       Andreas L Delmelle <a_l.delmelle () pandora ! be>
Date:       2006-07-27 21:56:23
Message-ID: 3F3A61D6-5F31-4F0B-8717-7732B349D5C8 () pandora ! be
[Download RAW message or body]

On Jul 27, 2006, at 18:54, Karthik wrote:

> Coming back to profiling, I tried taking a snapshot of the heap  
> after a FOP
> conversion using Jprobe and Jprobe reports "CondLengthProperty" as  
> the loitering
> object. Not very familiar with analyzing this further. I have a  
> snapshot file
> and some screen prints of Jprobe, not sure how to post it in this  
> forum.

Well, best to avoid posting large attachments to the list, as you  
will force every subscriber to download them.

Maybe we could also move this whole discussion to Bugzilla, and add  
those files as attachments over there. Benefit is that, even when we  
don't immediately have the time to look further, there will be a  
constant reminder to look into this.

> But this is how the reference tree to the object looks like  :
>
> Root -> AreaTreeHandler -> XMLWhiteSpaceHandler -> Block ->  
> TableCell ->
> CommonBorderPaddingBackground -> CondLengthProperty ->  
> CondLengthProperty

Hmm... So, are you sure *all* these CondLengthProperty instances have  
this same reference tree? Or did you check only one?

Attempt at interpretation:
In itself, *one* of these trees at a given point in the process is  
certainly nothing to worry about. The WS-handler keeps a reference to  
the current block. That block references its parent, a TableCell,  
which references its own properties, and a length-conditional  
property holds a reference to its corresponding property --e.g.  
padding-before<->padding-top, depending on whether 'before' maps to  
'top' given the writing-mode and reference-orientation).
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.

At most, we could try nulling this out explicitly in  
PageSequence.endOfNode(), but I'm not sure if that is going to make  
much of a difference. It *may* result in those objects being GC'ed  
sooner, but that ultimately depends on the JVM. :/

> Not sure if I am doing the right thing, but I'm willing to help or  
> contribute
> further on this.

Something that could also be of use to judge this completely is an  
example of a FO-file (note: NOT the XML+XSLT, but the result of the  
XSL transform, because that ultimately is the input for FOP) Is it  
possible for you to generate one with Xalan or Saxon? Use a source  
XML with non-confidential dummy data. It doesn't need to be large,  
but just enough to give us an idea of what a typical document looks  
like for you --so we only have to imagine it a thousand times larger.  
(Or did you already send one to this list in the past?)


Thanks,

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]