> -----Original Message----- > From: Thomas DeWeese [mailto:[EMAIL PROTECTED] > Sent: dinsdag 8 juli 2003 11:49 > To: [EMAIL PROTECTED] > Subject: Re: Out of memory loading big document > > > Hi Harm, > I think you might have miss understood. when I say 'text > node" I mean > node.getNodeType() == TEXT_NODE not Element nodes with the tag 'text' > (that have text > nodes as children in order to be useful). The GVT builder just skips > these and only looks at > the Element nodes.
No I understood :-p. I've altered my copy of GVTBuilder so that it processes ELEMENT_NODES and deletes those (after buildGraphicsNode) and everything else, so also text node, Cdata, etc. Before you made changes to CVS, this didn't work. Now with your latest changes in CVS everything works like a charm. The nodes are being GC'ed (I can clearly see huge drops in the Memory monitor when loading the document). The document loads without any problem. > Until the patches I committed last night the were certainly not > getting GC'ed. I believe that with > the current CVS they will get GC'ed. >If you get current CVS and you > suspect they are not > getting GC'ed the class batik.util.CleanerThread can be > easily used to > trace when/if objects are > GC'ed (create a small subclass of CleanerThread.SoftReferenceCleared > that prints something when > it's 'cleared' method is called (you might want to ferret away > object.toString() on construction)). Thanks for pointing that out, I haven't used this approach, like I said, Squiggles memory monitor is what I used :-P. Now I can see a clear distinction between documents that keep the DOM and loading that same document while deleting nodes, so I think it's safe to assume that they are GC'ed. But my solution works only on complete static documents so if a 5mb dynamic or interactive file is loaded, then it wont work unfortunately. I'm not sure if it is required to have the TEXT_NODES that represent the carriage returns and indenting in there. Perhaps Batik can delete those by default so that more memory is freed up for the more important things? This is just a thought, I'm not an XML/SVG expert, to me those carriage returns seem like overhead. On the other hand, I don't know how much memory they eventually take up. My 2 cents. thanks for the help Thomas! I'm going to inspect your changes so I try to understand why those nodes weren't GC'ed before. Regards, Harm > >-----Original Message----- > >From: Thomas DeWeese [mailto:[EMAIL PROTECTED] > >Sent: maandag 7 juli 2003 21:02 > >To: [EMAIL PROTECTED] > >Subject: Re: Out of memory loading big document > > > > > >Thomas DeWeese wrote: > > > > > > > >>Harm Cuppens wrote: > >> > >> > >> > >>>Hi all, > >>> > >>>I'm experiencing java.lang.OutOfMemoryError when trying to > load a big > >>>svg file (a whopping 5.35MB). I have the latest CVS > version of Batik. > >>> > >>>The document i'm loading is static, so I've been trying to > delete the > >>>dom elements as soon as they have been converted to their > >>>corresponding gvt equivalents (in GVTBuilder) in the hope > to free up > >>>some memory. Unfortunately I haven't been successful to get rid of > >>>the outofmemory error. This process is also terribly slow because > >>>each removal of a node checks if the node is a child of > the parent we > >>>wish to remove it from and the parent contains 40.000 > nodes. But that > >>>is not batik's fault but the way DOM works. > >>> > >>> > >> It sounds like something funny is going on here. As long as you > >>are deleting nodes from start to finish the removal time should be > >>quite good. You might want to check that you delete > >>TextNodes between the elements (I'm guessing that you have an equal > >>number of Element nodes > >>and Text nodes in the DOM as generally your element nodes have > >>whitespace between them > >>(like a newline + indenting) - if you don't remove these as well as > >>the real elements it could > >>get slow to find the last few elements. Also this should > help memory > >>use quite a bit. > >> > >> Can you tell if the nodes you are removing are getting GC'd? > >> What are the nodes, shapes, text, use? > >> > >> > > > > Using the new Memory Leak tests, I have verified a huge > memory leak > >that prevented any > >DOM node from going to GC if it was read from a stream (as > opposed to > >nodes created > >through script). This is now fixed and the change will be committed > >later tonight. > > > > The comments on removing TextNodes still stands. > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
