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]
