[kaffe] memory leak in jit3 ?

[Timothy Stack]

On Saturday, December 28, 2002, at 11:03  AM, Dalibor Topic wrote:

> Hi,
>
> I've taken a second look at the pure java zip from GNU
> Classpath.
> I compared memory consumption using -verbosemem on
> i386-linux with
> jit3. I saw a big difference between jit-temp-data for
> the pure java
> zip and native zip version.
>
> Here are the stats for the pure java version:
> The funny thing is that the jit-temp-data doesn't go
> away after a
> while, as the name "temp-data" implies. My question is
> : how can I
> figure out if this is a memory leak?

Most of the "temp" allocations are actually kept around across
runs of the jitter.  The seq/label/constpool infrastructure just make
lists of objects and resize them when more are needed.  However,
it does seem unlikely they would be keeping 3 megs of objects
around.  So, you might want to start there and make sure that the
lists aren't being broken and objects lost.  What test case are you
using?

There is actually a leak in the jitter, but as far as i know, it only
happens on an error condition, which seems unlikely in this
case.  The offending line is a malloc around machine.c:676, it
should either be changed to a realloc or the codeblock variable
should be freed somewhere besides finishInsnSequence().

> I've also looked at the JanosVM 0.8 sources for jit3
> and found that
> they are using a resetConst call to reset the constant
> pool. There is
> no such thing in current kaffe sources. Could merging
> in the JanosVM
> jit3 changes have a positive result on jit-temp-data
> usage ?

Possibly, i can run a test case on our current internal version
and report the results...

> best regards,
>
> dalibor topic

tim stack