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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
