You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thierry Kormann <tk...@sophia.inria.fr> on 2001/04/18 17:20:18 UTC

memory leak

Hi,

While trying to debug the apacheCon.svg huge file (with the linking), I found 
a memory leak. The error appears while browsing the document (using 
#svgView(viewBox...)).

PS: I have activated the debug traces and I am sure that only rendering 
operations are performed (the document is never reloaded, that is already a 
start :).

I think it's the first time we combine both the new internal linking and the 
new renderer algorithm. As changing the #viewBox implies only a call (summary 
:) to the renderer.setTransform method, I imagine that the memory leak could 
be in the renderer.

I have noticed something that might be interesting. When changing from slide 
to slide, the transform is just a translation and after several slides, I got 
my OutOfMemoryException.

When reseting the transform sometimes (using 'Initial transform' menu item), 
a huge block of memory goes to GC and I am able to continue.

Perhaps, the renderer is caching too many (all?) tiles when a pan is 
performed (in this case, tiles are huge (1024x768 each time). As the 'Initial 
View' item generates a scale, the tiles could be invalidated (and so go to 
GC).

Any comments?
Other ideas?

Thierry.



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org


memory leak

Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <tk...@sophia.inria.fr> writes:

TK> Hi,

TK> While trying to debug the apacheCon.svg huge file (with the
TK> linking), I found a memory leak. The error appears while browsing
TK> the document (using #svgView(viewBox...)).

TK> When reseting the transform sometimes (using 'Initial transform'
TK> menu item), a huge block of memory goes to GC and I am able to
TK> continue.

TK> Perhaps, the renderer is caching too many (all?) tiles when a pan
TK> is performed (in this case, tiles are huge (1024x768 each
TK> time). As the 'Initial View' item generates a scale, the tiles
TK> could be invalidated (and so go to GC).

TK> Any comments?  Other ideas?

    Try changing line ext.awt.image.rendered.AbstractTiledRed.java:248 :

-        return TileCache.getTileGrid(this, this);
+        return TileCache.getTileMap(this, this);

    If my hunch is right this should _greatly_ improve things, but may
not solve the problem entirely (in particular if you pan to all parts
of the document (including the fairly large 'blank' areas) you may
still get an out of memory exception.

    My hunch is that the problem is the array of tile references it's
self (not the tiles in the grid), the TileGrid allocates a row of tile
references when the first tile in that row is requested.  So I'm
guessing the problem will almost always occur when panning vertically
not horizontally.

    If this is the case then the TileMap still needs some work since
eventually you may fill the Map with so many 'empty' weak refs that
you run out of memory there.  So I need to add a reference queue and a
thread that waits on them and removes the empty weak entries from the
hash when the reference is cleared (something similar should be done
for the URLImageChache as well I'll try and make it general).

    Do you understand the problem?

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org