This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Help finding memory leaks in gcj 3.3


It seems that there are two memory leaks in the
libgcj:

1. Every call to java.util.Calendar.getInstance
creates a new (currently uncollectible) class. The
same is true for the deprecated methods which call
Calendar.getInstance() internally. This is probably
okay, because Calendar.getInstance() is known to be
expensive.



2. From natStackTrace.cc:

frame = (_Jv_frame_info *) _Jv_Malloc (len * sizeof
(_Jv_frame_info));

The _Jv_Malloc seems to a wrapper for the plain
malloc() function (from prims.cc). The above allocated
memory will never be reclaimed.





Anyhow, the next problem is odd: If I link my
application explicitly against the libgcjgc.so (right
before the libgcj.so), then the amount of memory stays
bound, if not, then the memory grows until an out of
memory error occurs.

The only reason I can think of is that the GC has
traced false pointers. Probably this a known problem?



> If you could get gcj to do all

> allocation through the GC_debug... routines (or if
you fixed the GC to

> no longer require this) and if you built the
collector with 

> -DKEEP_BACK_PTRS, then you could use the
gc_backptr.h interface to 

> randomly sample objects in the heap, and ask why
they are reachable.



In theory this sounds easy (except that some gcj code
directly accesses the gc internals). But somehow I got
lost reading the code with all the #ifdefs. :)

?

Jost



__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]