Hi Michael,
"Bishop, Michael W. CTR USJFCOM JFL" <[email protected]> wrote
on 02/22/2009 11:06:50 PM:
> One more question. If this fix works, how hard would it be for me
> to "patch" it into the 1.7 release?
I think it would be simple.
> We're very close to a release on our software and I'm trying to minimize
> changes for testing. Does the fix touch a couple of files, or is it
> dependent on a lot of other post-1.7 changes?
You can view the changes at:
http://svn.apache.org/viewvc?view=rev&revision=746059
There is some risk that calling disposeTree might
cause an error in some case, but since we call disposeTree
anytime an element is removed from the DOM (like during
scripting) I think the likelihood is small.
> ________________________________
>
> 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
yousuggested.
> > >
> > > 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: batik-users-
> [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]
> [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
