Detecting memory leaks

Thu Sep 23 07:55:00 GMT 2004

Thanks for the hint! If I understand correctly, it is C, not GC:
--> Marking for collection 3 after 538172 allocd bytes + 177516 wasted
bytes
Collection 2 finished ---> heapsize = 1011712 bytes
World-stopped marking took 30 msecs
Complete collection took 40 msecs
...
--> Marking for collection 1011 after 529980 allocd bytes + 144748 wasted
bytes
Collection 1010 finished ---> heapsize = 1011712 bytes
World-stopped marking took 30 msecs
Complete collection took 40 msecs
For some reason, I didn't get any additional output from
GC_DUMP_REGULARLY.
Are there any tools that can help me from there? I know that in
general there are many tools, but are they applicable to gcj and ARM (it
seems that I'm too lazy to try them myself ;) ?
On 2004年9月22日, Hans Boehm wrote:
> A good first step is probably to determine whether the GC heap or the C
> heap is growing. Setting the GC_PRINT_STATS and/or GC_DUMP_REGULARLY
> environment variables should tell you that. (The latter produces lots of
> output on large GC heaps.)
>> Hans
>> On 2004年9月22日, Jari Korva wrote:
>> > Hi,
> >
> > are there any easy to use tools for finding gcj memory leaks, especially
> > on ARM/XScale? For example the following code seems to leak on
> > armv5l (gcj 3.4.0) and armv5b (gcj 3.4.2), but not on x86 (gcj 3.4.0):
> >
> > import java.net.*;
> >
> > public class MemLeakTest
> > {
> > public static void main(String args[])
> > {
> > for(;;)
> > {
> > try {
> >
> > URL url = new URL("http://princess.willab.fi:8111/");
> > URLConnection conn = url.openConnection();
> > System.out.println(conn.getContentType());
> > conn.getInputStream().close();
> >
> > } catch(Exception e) {
> > e.printStackTrace();
> > }
> > }
> >
> > }
> > }
> >
> > Cheers,
> > Jari
> >
> > --
> > - Jari Korva -
> >
>
 - Jari Korva -
 - jari.korva@iki.fi -
 - http://www.iki.fi/jpkorva/ -
 - +358-40-756 4812 -