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