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
