You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Andrew Plotkin <er...@eblong.com> on 2005/12/07 22:49:50 UTC
Memory leaking from MultipleGradientPaintContext
Consider the document <http://www.eblong.com/zarf/tmp/splat.svg>. It's a
small interactive thing: click and drag the mouse, and the green
transparent bar follows you. Also, pretty gradient background.
This works on my friend's Mac (OSX 10.3.9). On my Mac (OSX 10.4.2), Java's
heap fills up. The more I move the mouse, the more memory gets used. (But
only if I'm dragging the green bar across the four green shapes!) I hit
java.lang.OutOfMemoryError very quickly -- about fifty mouse-move events.
I'm using a snapshot of the SVN repository from 2005-Nov-13. I fetched it
with "svn checkout -r 333250
http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk". (I grabbed this
in order to pick up the "slow rendering on OSX 10.4" fix that circulated a
couple of months ago.)
I have mostly done this testing in my own app, but it happens in Squiggle
also -- the Squiggle at SVN 333250, that is. It does *not* happen with the
Squiggle from your last public release.
I did some excavation with java's profiling option (-Xrunhprof). Turns out
that what's clogging memory is gigantic int arrays, coming from inside
MultipleGradientPaintContext. The top of the call stack in question:
java.awt.image.DataBufferInt.<init>(DataBufferInt.java:41)
java.awt.image.Raster.createPackedRaster(Raster.java:452)
java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1015)
org.apache.batik.ext.awt.MultipleGradientPaintContext.getCachedRaster(<Unknown>:Unknown line)
org.apache.batik.ext.awt.MultipleGradientPaintContext.getRaster(<Unknown>:Unknown line)
apple.awt.OSXSurfaceData.setupPaint(OSXSurfaceData.java:709)
apple.awt.OSXSurfaceData.setupGraphicsState(OSXSurfaceData.java:1013)
apple.awt.OSXSurfaceData.setupGraphicsState(OSXSurfaceData.java:978)
...etc
So it's creating a big raster (the size of the window) for my
SpaceGradient gradient object; and the raster never gets freed. Repeat
fifty times, and Java falls over.
(I see that MultipleGradientPaintContext has a weak-reference caching
mechanism. I don't quite grok how it works, but it obviously isn't working
for me. (Perhaps the cache is failing to handle the alternation of
requests at different sizes?) But even without the caching, it's a bug
that these rasters are being retained.)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Memory leaking from MultipleGradientPaintContext
Posted by Andrew Plotkin <er...@eblong.com>.
On Tue, 13 Dec 2005, thomas.deweese@kodak.com wrote:
> However what I really need to debug the problem is an idea of why those
> int arrays aren't going to GC. Since they go to GC on other JVM's I'm
> inclined to blame something internal to the 10.4 JVM, the key question is
> what? and is there anything I can do to avoid the problem...
>
> Do you have tools to debug memory leaks? I.E. follow reference chains
> backwards to the GC root keeping the array live.
You probably thought I'd given up on this question... :) Sorry, it took me
a while to get back to this.
I went through a lot of memory-leak debuggers, all of which didn't work. I
eventually wound up dumping an XML representation of the heap (with
jmap) and analyzing it myself. And boy, are my arms tired. Blah.
Anyway, what I have found:
* Memory leaks much more slowly under a JDK1.5 VM. (java version
1.5.0_05). My previous tests were all under 1.4.2_09.
* When I finally dug out the leaked rasters, I found that they weren't
live at all -- they were stuck in reference loops. (This was a 1.5.0
test.) So my guess is that the 1.5.0 VM is being smarter about cleaning up
reference loops, but it still doesn't catch them all -- not as fast as I
can generate them with my test SVG document, anyway.
* None of the objects involved in the reference loop are from Batik.
Unfortunately the XML heap dump is not very informative... I can tell one
of them is java.awt.image.Raster, which is not a surprise. The Raster has
a "listener" field that points to something that has a "bufImgRaster" link
back to the Raster. There are a couple of other objects that loop through
the Raster as well. It's quite possible that these are Mac-specific image
classes.
So I can't see that Batik is doing anything illegal. (There is no
"deallocate" method to use when throwing away a Raster.) However, it is
creating big Rasters every time the document updates, and then throwing
them away. This combines poorly with drag-and-drop SVG interfaces.
Better caching of Rasters in MultipleGradientPaintContext would work
around the problem. But I don't know how easy it would be to do it right.
I'm not sure where to go next with this. I can't tell all my Mac users to
use JDK 1.5.0. (It's supported on Macs but it's not the standard
environment. Maybe when OSX 10.5 comes out...)
I suppose the "right" solution is to make that "listener" field a weak
reference. Does anyone know enough about internal java.awt.image stuff to
know who I should go to about that? I can describe the fields of the
objects in the loop, if that'll help anyone recognize them.
Thanks.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Bush's biggest lie is his claim that it's okay to disagree with him. As soon as
you *actually* disagree with him, he sadly explains that you're undermining
America, that you're giving comfort to the enemy. That you need to be silent.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Memory leaking from MultipleGradientPaintContext
Posted by Andrew Plotkin <er...@eblong.com>.
On Tue, 13 Dec 2005, thomas.deweese@kodak.com wrote:
> However what I really need to debug the problem is an idea of why
> those int arrays aren't going to GC. Since they go to GC on other JVM's
> I'm inclined to blame something internal to the 10.4 JVM, the key
> question is what? and is there anything I can do to avoid the problem...
>
> Do you have tools to debug memory leaks? I.E. follow reference chains
> backwards to the GC root keeping the array live.
I apologize for being an utter failure on this question, but... I just
spent several hours looking for tools to accomplish this, and I'm failing.
Utterly.
(HAT: bad magic number reading HPROF dump. jMechanic: class load error
when I start a profile run in Eclipse. Eclipse TPTP: I can't even figure
out what to install. JMP: won't compile on Mac. DrMem: doesn't report
reference chains.)
If anyone has a clue how to accomplish this kind of debugging on a Mac
(and a JDK 1.4.2 environment), I'd truly love to hear from you...
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Memory leaking from MultipleGradientPaintContext
Posted by Andrew Plotkin <er...@eblong.com>.
On Tue, 13 Dec 2005, thomas.deweese@kodak.com wrote:
> Do you have tools to debug memory leaks? I.E. follow reference chains
> backwards to the GC root keeping the array live.
I do not, right at the moment. I will look into some and try to find more
information.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Memory leaking from MultipleGradientPaintContext
Posted by th...@kodak.com.
Hi Andrew,
I don't have read access to a 10.4.2 machine. I've delevered a small
bug fix that
should at least help the situation.
However what I really need to debug the problem is an idea of why those
int arrays
aren't going to GC. Since they go to GC on other JVM's I'm inclined to
blame
something internal to the 10.4 JVM, the key question is what? and is there
anything I
can do to avoid the problem...
Do you have tools to debug memory leaks? I.E. follow reference chains
backwards
to the GC root keeping the array live.
Andrew Plotkin <er...@eblong.com> wrote on 12/12/2005 10:57:05 PM:
> On Wed, 7 Dec 2005, Andrew Plotkin wrote:
>
> > Consider the document <http://www.eblong.com/zarf/tmp/splat.svg>. It's
a
> > small interactive thing: click and drag the mouse, and the green
transparent
> > bar follows you. Also, pretty gradient background.
> >
> > This works on my friend's Mac (OSX 10.3.9). On my Mac (OSX 10.4.2),
Java's
> > heap fills up. The more I move the mouse, the more memory gets used.
(But
> > only if I'm dragging the green bar across the four green shapes!) I
hit
> > java.lang.OutOfMemoryError very quickly -- about fifty mouse-move
events.
> >
> > I'm using a snapshot of the SVN repository from 2005-Nov-13.
>
> For laughs, I tried this with the current trunk ("Checked out revision
> 356460") and the bug still happened.
>
> --Z
>
> "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
> *
> I'm still thinking about what to put in this space.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Memory leaking from MultipleGradientPaintContext
Posted by Andrew Plotkin <er...@eblong.com>.
On Wed, 7 Dec 2005, Andrew Plotkin wrote:
> Consider the document <http://www.eblong.com/zarf/tmp/splat.svg>. It's a
> small interactive thing: click and drag the mouse, and the green transparent
> bar follows you. Also, pretty gradient background.
>
> This works on my friend's Mac (OSX 10.3.9). On my Mac (OSX 10.4.2), Java's
> heap fills up. The more I move the mouse, the more memory gets used. (But
> only if I'm dragging the green bar across the four green shapes!) I hit
> java.lang.OutOfMemoryError very quickly -- about fifty mouse-move events.
>
> I'm using a snapshot of the SVN repository from 2005-Nov-13.
For laughs, I tried this with the current trunk ("Checked out revision
356460") and the bug still happened.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org