> We already try to do this. Clearly we succeed at least in the simple case > (otherwise your simple case would have > problems also). Well the simple case only alternates between two pages. If both pages pick up that extra information without running out of memory, then I don't think I would see the problem. Is more information possibly added every time you view a page, or only once per page? I was going to do some more looking. The "test case" inside my actual application is about 10 pages. I can get to page 8 before I run out of (the standard 64M) memory. I will try the latest SVN build and see what happens. Out of curiousity, is there a way to do whatever is supposed to be done directly on an SVGOMDocument? Before I tried your fix, I did start using DOMUtilities to clone the document before removing it from the page and that seems to work. I will revert to the older code when I try the latest Batik SVN. Thanks for looking into this. I was doing quite a bit of profiling trying to figure it out. Michael
________________________________ From: [email protected] [mailto:[email protected]] Sent: Fri 2/20/2009 5:42 AM To: [email protected] Cc: [email protected] Subject: RE: Memory leak switching documents? Hi Michael, I've checked in a possible fix for this. Can you check the head version in SVN? [email protected] wrote on 02/19/2009 06:48:56 AM: > "Bishop, Michael W. CTR USJFCOM JFL" <[email protected]> > wrote on 02/17/2009 12:53:09 PM: > > > When I switch pages, it appears that the individual > > SVGDocument objects still retain information (BridgeContext) > > belonging to the canvas after they've been removed from the canvas. > > This is about 2.5M. > > org.apache.batik.bridge.BridgeContext @ 0x7f84fac57060 | 288 | 2,460,040 > > > > '- ctx org.apache.batik.bridge.SVGDocumentBridge @ 0x7f84fac7c810 | 40 | 40 > > > > '- svgContext org.apache.batik.dom.svg.SVGOMDocument @ > > 0x7f84fab62660 | 256 | 7,008 > > This is very helpful. It indicates that disposeTree isn't getting > called when the document is removed from the Canvas. I suspect this > is a bug in the BridgeContext.dispose() method. I'm trying to track > down where (if ever) we call(ed) disposeTree. > > > > > > '- svgDocument mil.jfcom.cie.whiteboard.whiteboard.Page @ > > 0x7f84fb12edf0 | 40 | 40 > > > > '- [0] java.lang.Object[38] @ 0x7f84fb12b208 | 328 | 502,928 > > > > '- elementData java.util.ArrayList @ 0x7f84fb12b1e0 | 40 | 502,968 > > > > '- pages mil.jfcom.cie.whiteboard.whiteboard.Whiteboard @ > > 0x7f84fb12b1a8 | 56 | 503,024 > > > > '- whiteboard mil.jfcom.cie.whiteboard.ui.managers.WBManager @ > > 0x7f84fa899a08| 48 | 503,072 > > > > |- wbManager mil.jfcom.cie.whiteboard.ui.WBPageControlBox @ > > 0x7f84fa8c0d90| 664 | 20,296 > > > > |- wbManager mil.jfcom.cie.whiteboard.ui.WBPagePanel @ > > 0x7f84faba8df0 | 632 | 118,896 > > > > '- Total: 2 entries | | > > > > > ------------------------------------------------------------------------------------------------------------------------------ > > > > Michael > > > > ________________________________ > > > > From: Bishop, Michael W. CTR USJFCOM JFL [mailto:michael.bishop. > [email protected]] > > Sent: Tue 2/17/2009 10:52 AM > > To: [email protected] > > Subject: RE: Memory leak switching documents? > > > > > > Hi Thomas, > > > > > That doesn't compute for me. How can you run out of memory if > > > 8MB represents ~95% of the memory in use? 8MB is just 12% of the > > > available heap. > > > > My thoughts exactly. I have no idea why I have a heap graph that's > > steadily growing when the same profiler is reporting 8MB as 95% of > > the usage. It could be my lack of knowledge with profilers, but I'm > > not sure how to ask the heap what's using the rest of the memory. > > > > I have to do some looking around to find this "garbage collection > > root." All of these stack traces usually go back to a Thread.run() > > and not the "main" daemon/thread. > > > > The images in the SVG are linked via xlink:href. They are not > > embedded in the image. I've done some more testing in the past few > > days. It appears that memory usage grows with any SVG document > > whether or not it contains an image. > > > > I coded a quick example with a JSVGCanvas to switch between SVG > > documents at 5 second intervals. The memory usage in this example > > is level; the heap grows until a GC and then it levels back out. So > > in the most basic of cases, I get expected behavior. > > > > Michael > > > > ________________________________ > > > > From: [email protected] [mailto:[email protected]] > > Sent: Wed 2/11/2009 5:37 AM > > To: [email protected] > > Cc: [email protected] > > Subject: RE: Memory leak switching documents? > > > > > > > > Hi Michael, > > > > "Bishop, Michael W. CTR USJFCOM JFL" <[email protected]> > > wrote on 02/09/2009 01:05:12 PM: > > > > > However, my heap size is still growing and ~10 page changes will > > > cause an OutOfMemoryException error with the default (64M) heap > > > size. The profiler doesn't show any other classes eating a lot of > > > memory. int[] at 8172k is 94.5% of the total memory the profiler's > > > heap dump tracks. > > > > That doesn't compute for me. How can you run out of memory if > > 8MB represents ~95% of the memory in use? 8MB is just 12% of the > > available heap. > > > > > As for the stack trace for int[] allocations, it's all internal to Batik. > > > > I wasn't asking about the stack trace for int[] allocations. > > I was asking what the Garbage collection root (GC Root) was for > > the arrays. The only way an object can avoid GC is be being > > referenced by a GC root or another object that is referenced by > > a GC root. Examples of GC roots are any class static variables, > > and variables on the stack (these are the main two). > > > > Typically memory profilers will let you walk back along the > > chain of references till you reach a root. Knowing what that > > chain is, is the most useful piece of information for fixing > > memory leaks like this. > > > > > For the record, this is Batik 1.7 final with Java 1.6u11 (Windows > > > XP). I'm still doing some digging and learning profiling in > > > general, but I wanted to report the results of the changes you suggested. > > > > BTW you said the document's consisted of basically just an > > 'svg' and an 'image' element. Does the image element reference > > an external file or is the image base64 encoded in the file itself? > > > > > From: [email protected] [mailto:[email protected]] > > > Sent: Mon 2/9/2009 6:26 AM > > > To: [email protected] > > > Cc: [email protected] > > > Subject: Re: Memory leak switching documents? > > > > > > > > > > > > Hi Mochael, > > > > > > "Bishop, Michael W. CTR USJFCOM JFL" <[email protected]> > > > wrote on 02/02/2009 01:19:07 PM: > > > > > > > I "lose" memory every time I switch pages by calling > > > > setDocument(...) on the JSVGCanvas. It appears from profiling that > > > > this is mostly due to image loading. > > > > > > > > The increasing memory seems to come from int[] created as: > > > > > > This is the image loading code. The question is can you > > > tell what continues to reference the 'old' images? Most > > > Memory profiling tools can give you the reference chain to a > > > GC root from an object. > > > > > > > When I switch documents about 10 times, I get an > > > > OutOfMemoryException. While I keep the SVGDocuments in memory, I > > > > don't load and keep images or JSVGCanvases. It's one JSVGCanvas > > > > used to display whatever "slide" (document) the user wants to see. > > > > Are there some references I can tell the JSVGCanvas to release? > > > > > > I'm fairly certain the problem is that you keep the Document in > > > memory after it has been displayed in the Canvas (this shouldn't be > > > a problem but I'm guessing it is). You could test if this is the > > > problem by cloning the Document either before you show it (so you > > > hold onto the original and display the clone) or when you are done > > > showing it (so you hold the clone and the canvas will drop the > > > reference when it switches to the next document). If this solves > > > your problem then it indicates that we are leaving junk attached to > > > the SVG DOM (which we shouldn't be after the document is detached > > > from the canvas). > > > > > > > Are there any gotchas I should look for? I'm trying to figure out > > > > if I'm doing something wrong specifically in my application or there's > > > > a common pitfall that I can be pointed to so I can avoid this memory > > > > consumption. > > > > > > We do try hard to keep an eye on memory leaks, so I'm not 100% > > > certain the problem is entirely with Batik. > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC] > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC] > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
