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
_______________________________________________
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
