Re: [PATCH] Freeing area tree memory
Il giorno 14/ott/08, alle ore 00:15, Dario Laera ha scritto: 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? I realized I was wrong... I've attached a new patch that deals only with parent area and doesn't free any LM. This patch adds also an "implements Serializable" in a class that gets cached with the area tree, and adds a command line flag to enable caching. The changes in this patch are not always necessary, but in many cases can saves lots of memory. Dario freeAreaTree2.diff Description: Binary data
Re: [PATCH] Freeing area tree memory
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 ;) Dario
Re: [PATCH] Freeing area tree memory
Hi Dario, Dario Laera wrote: > Hi all, > > I wrote a patch that fixes a memory leak making FOP freeing areaTree > memory after rendering (or caching) a page within a page-sequence > processing: with this patch since the first page areaTree has been > completed, the memory consumption is almost constant until the end of > the page-sequence. With some more lines of code that frees ChildContext > and some peripherals LM the amount of memory used even decreases. > I didn't get any error in the test I run, I ask the list if this patch > do have side effects I didn't catch. In particular, it seems to me that > the changes in BlockLM and LineLM are the more unsafe. 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. 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. 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 Thanks, Vincent
