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
[PATCH] method invocation via jni (was Re: [kaffe] java.lang.reflect.Method virtual method call bug (CVS))
On Sat, 28 Dec 2002 15:33:01 +0100 Helmer Krämer [EMAIL PROTECTED] wrote: Hi all, replying to myself here. P.S.: Sorry if this was a little bit confusing, I'll send a complete, cleaned-up patch of these changes when gzz is working I've revised my first patch a little bit (the last version would've caused problems with intrp) and included a ChangeLog entry and an updated regression test. Greetings, Helmer interface-patch.bz2 Description: Binary data
Re: [kaffe] [bug] kaffeh can't handle overloaded native methods
On Fri, 27 Dec 2002 15:00:14 -0800 (PST) Dalibor Topic [EMAIL PROTECTED] wrote: Hi Dalibor, So I'd be glad if someone with more kaffeh hacking experience could take a closer look at it and tell me if I'm missing something obvious. As a bit of background motivation, this is the last bit holding back the merge of the ALSA based sound backend from tritonus.org. AFAIK, readClass simply calls addMethod for each method in the class file so that you won't get an initialized CLASS_METHODS in kaffeh since its addMethod does nothing but generating a c declaration if necessary. Since I was already digging through the sources, I've attached a small patch that seems to work for me (it's just a quick hack, so don't take it too seriously ;)). Greetings, Helmer kaffeh-patch Description: Binary data
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
