Re: [kaffe] memory leak in jit3 ?
Hi Tim, --- Timothy Stack [EMAIL PROTECTED] wrote: 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? You need to apply the GNU Classpath java.util.zip replacement patch, available at http://www.kaffe.org/~robilad/zip-replacement-patch.tgz and to copy the Klasses.jar.bootstrap file over the existing copy in libraries/javalib. After installing the patched version of kaffe, simply running its jar tool on rt.jar as in kaffe -verbosemem kaffe.tools.jar.Jar xvf rt.jar should show more than 3 MB of jit-temp-data. best regards, 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
Re: [kaffe] memory leak in jit3 ?
On Sunday, December 29, 2002, at 08:03 AM, Dalibor Topic wrote: Hi Tim, hi You need to apply the GNU Classpath java.util.zip replacement patch, available at http://www.kaffe.org/~robilad/zip-replacement-patch.tgz and to copy the Klasses.jar.bootstrap file over the existing copy in libraries/javalib. After installing the patched version of kaffe, simply running its jar tool on rt.jar as in kaffe -verbosemem kaffe.tools.jar.Jar xvf rt.jar should show more than 3 MB of jit-temp-data. Yep... the problem? The jitter sucks :). 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. 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. best regards, dalibor topic tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] memory leak in jit3 ?
--- 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
Re: [kaffe] memory leak in jit3 ?
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
