xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dario Laera <la...@cs.unibo.it>
Subject Re: [PATCH] Freeing area tree memory
Date Mon, 13 Oct 2008 22:15:02 GMT
Hi Vincent,

first of all, thanks for your reply.

Il giorno 13/ott/08, alle ore 13:27, Vincent Hennebert ha scritto:
> A good way to test your modifications is by running the test suite:
>    ant junit
> While this doesn’t assure you that your patch is 100% correct, this at
> least gives you a good indication. Now, if I run the test suite on
> a patched Trunk I have an infinite loop somewhere, so there seems to  
> be
> a problem in your modifications.

Probably it isn't an infinite loop, but the debug code that I forgot  
to comment out... The patch adds in RenderPagesModel.java many calls  
to the garbage collector and this makes FOP running very slow.
Anyway, I've run junit, I didn't checked the direct output (there are  
many FATAL, WARN and other messages also in trunk) but I looked at  
junit-reports. At the first run with patched FOP I obtained tons of  
errors in layout manager tests, but it seems to me that those are due  
to the fact that junit checks the areaTree generated to see if the  
result is correct, while I voluntarily freed some part of the  
areaTree. So I switched the render model from the cached to the  
classical one while leaving unchanged the rest of the patch: in this  
way the areaTree doesn't get collected while the LMs loose the pointer  
to the areas, so the test *should* be valid anyway. With the classical  
renderer no error were reported.

> You’re probably too aggressive in
> freeing objects that are actually re-used. Note that the addAreas  
> method
> are called once per page on which the object relies; so you have to be
> careful to not release information that may still be needed for
> following pages. Sorry I can’t study your changes in more details at  
> the
> moment.

If I understood correctly, the parentArea of a LM instance points to a  
new area each time it's called to create areas for a new page: a table  
that spans in 10 pages will point to 10 areas in the instance life  
time. So freeing parentArea shouldn't be a problem.
The LMs I free are the LineLM (and, obviously, relative children): by  
definition, they shouldn't span in many pages. Am I correct?

> As a side note, watch for tab characters in your source files; they  
> are
> illegal in the FOP project. Don’t forget to run checkstyle before
> submitting a patch. See here for information about how to set up the
> Checkstyle plugin in various development environment:
> http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide

... sorry ;)


View raw message