[kaffe] memory leak in jit3 ?

[Dalibor Topic]

--- Timothy Stack <stack at cs.utah.edu> wrote:
> The thing thats tickling the bug is the static
> initializers
> in UnicodeTbl/UnicodeIdx.  They are so large that
> they
> need a ton of memory to be compiled.  So they force
> the jitter's label/const/seq object pools to be
> grown to
> an enormous size.  Since these are not bounded, they
> end up staying around for the rest of the run.

Yeah, initializing byte arrays is something java
bytecode seems to be really bad for ... that's why the
code so large. I might give classpath's CharData code
a shot, though. They use Strings ;)

> As for possible solutions?  The quick and dirty way
> would be to just bound the pool sizes to some
> reasonable limit.  The best solution would be to fix
> the jitter since the peak usage is still ginormous.

Does the jitter really need all of that data
(labels/const/seq objects) after it has finished
dealing with a method? I'd think a quick & dirty
solution would be to just "free" the object pools once
the jitter is done with them.

Nevertheless, that wouldn't take care of peek usage.
Where should we start fixing it? I have only browsed
that code so far, and found your docs for janosvm
quite helpful ...

cheers,

dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com