Hi Tania,
Richter, Tania wrote:
the roots of the leaked objects are (as far as I could analyze it):
org.apache.batik.swing.svg.GVTTreeBuilder.run()
org.apache.batik.swing.gvt.GVTTreeRenderer.run()
org.apache.batik.swing.svg.SVGDocumentLoader.run()
org.apache.batik.util.EventDispatcher.run()
org.apache.batik.swing.svg.JSVGComponent.stopThenRun()
Well I'm a little unsure why it includes a method name ('run')
in the root specification, but I think all the above refer to
worker thread objects that must have exited by the time you
are taking your snapshot.
So I am fairly convinced that everything is fine (there are
no leaks). If you want to you can check if those thread
object are still running (check the active threads and see if any
of them have the above as the 'root' method in the stack trace)?
If those objects aren't still running then they aren't "real" roots
(i.e. the roots are eligible for GC).
With OptimizeIt I cannot run the incremental GC.
That makes it difficult for me to verify your suggestion.
But with OptimizeIt I call the garbage collector explicitly
so why should it not free unused references?
Because that is the way the generational GC works. If it
is happy with the free memory it won't look beyond the youngest
generation, even when you explicitly call for a GC. If you force
memory pressure you might be able to 'trick' it into looking at
older generations but I've tried to do this in our Memory leak
test and it is hard to do.
-----Ursprüngliche Nachricht-----
Von: Thomas DeWeese [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 31. August 2005 12:10
An: [email protected]
Betreff: Re: FW: Problem with memory leaks using SVGCanvas
Hi Tania,
My first impression of this is that you are seeing the effects
of the Generational Garbage Collector. It won't GC or even consider
elements for GC unless they are in the 'youngest' Generation or it
can't get enough memory from the youngest generation. In my
experience you will get more accurate results if you try using the
incremental Garbage Collector (-Xincgc). We have memory leak tests
as part of Batik and they generally 'fail' with the Generational GC
but work with the incremental GC.
Also to be useful I would need information on the roots of the
leaked objects.
Richter, Tania wrote:
in my Java application running under Windows I have one function that
uses the JSVGCanvas to display SVG graphics. When the function finishes
a lot of batik objects (about 2000) remain in the heap and are not
cleaned by the garbage collector , a.o. alot of object out of the
packages org.apache.batik.bridge, org.apache.batik.css.engine and the
following objects (OptimizeIt printout):
[...]
The JSVGCanvas itself is not longer there. When I call the function
several times it does not change the heap allocation significantly.
Is this a bug or what can I do to get the batik object completely freed?
Regards
Tania
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
