Hi Thomas,
That seemed to affect it. I overrode setDocument as follows:
public void setDocument(SVGDocument document) {
SVGDocument clonedDoc = null;
if (document != null) {
clonedDoc = (SVGDocument) document.cloneNode(true);
}
super.setDocument(clonedDoc);
}
When I first load the set of documents that comprise a whiteboard, int[] takes
202k of memory. After switching pages 8 times, the memory consumed is 8172k.
This is far less than it used to be. Before I overrode setDocument, it would
be 3M - 5M consumed for each page change.
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. Nonetheless, the heap
size still grows. Maybe something internal to the VM? I know profiling is
beyond the scope of this list.
As for the stack trace for int[] allocations, it's all internal to Batik.
It starts with:
org.apache.batik.ext.awt.image.codec.png.PNGRegistryEntry$1.run()
org.apache.batik.ext.awt.image.rendered.AbstractRed.getData()
org.apache.batik.ext.awt.image.rendered.AbstractRed.getData(java.awt.Rectangle)
java.awt.image.Raster.createWritableRaster(java.awt.image.SampleModel,
java.awt.Point)
java.awt.image.SinglePixelPackedSampleModel.createDataBuffer()
...and ends with:
java.awt.image.DataBufferInt.<init>(int)
I'm unable to track this memory usage back into my code. Still this is a
significant improvement. Now I've just got a heap size growing from some
phantom memory that the profiler isn't/can't track. I don't know why the
memory allocated here would keep growing.
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.
Michael Bishop
________________________________ 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] >
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
