Help finding memory leaks in gcj 3.3

[Bryce McKinlay]

On Wednesday, Oct 1, 2003, at 20:47 Pacific/Auckland, Jost Boekemeier 
wrote:

> 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.

Our Calendar.getInstance certainly looks a bit ugly and inefficient, 
however I don't think it could actually be leaking anything. 
Class.forName() doesn't create new clases, it just returns a reference 
to a class that usually already exists somewhere in the runtime. And 
yeah, "new Class[]" doesn't create classes either.

> 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.

Yup, the stack trace code really needs to be cleaned up. I filed a PR 
on this one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12475

> 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?

What platform? What version of GCJ? Although theoretically possible, 
given that the heap is scanned precisely and interior pointers are 
disregarded, the chances of significant amounts of false pointers in 
most applications is very small. So - not a known problem.

Regards

Bryce.