Re: Memory leaking from MultipleGradientPaintContext

[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