Hi Jared, sorry for the long delay, girlfriend trouble.
--- "Boone, Jared" <[EMAIL PROTECTED]> wrote: > The FAQ.embedded and FAQ.classlibrary-compile > documents in the Kaffe > source tree helped me reduce Kaffes ROM footprint. cool. how small did you get it ? > patch listed there is incomplete. If anyone is > interested in the patch, > please contact me and I will try to make it > available. Sure, but it's a patch to the linux kernel, not kaffe, right? I think in that case it would be nice to have a link to the discussion and the patch to point people to. > ZipInputStream.getNextEntry() seems to use up a lot > of RAM for large zip > entries. Kaffe's ram usage jumps by 1.4 Mb when I > call this method on a > ZipInputStream constructed from a FileInputStream > for a 4mb zip file > with a single entry. This is causing "Out of Memory" > errors on my > embedded device. I expect a ZipInputStream to use a > small buffer for > reading zip entries, as with a FileInputStream. Is > there a way to read a > zip entry without using so much RAM? The current Zip implementation uses libz to do the work. I've browsed though the java.util.zip sources, but I couldn't find an obvious scapegoat ;) You could try to use GNU Classpath's pure java zip implementation, and see if that helps. My experience with the pure java zip on an ipaq was rather bad regarding performance with the interpreter, somewhat tolerable with the jit on slow processors, and acceptable on fast processors. See http://www.kaffe.org/pipermail/kaffe/2002-December/028470.html for more information. The 2-6 MB memory incrase should no longer be the case with the current CVS. > My application loads a lot of classes. Is there a > faster alternative to > java.lang.ClassLoader.defineClass(null, byte[], int, > int)? you can speed things up a bit by providing a class name , and a protection domain. All other defineClass methods delegate to defineClass("name", byte[], int, int, ProtectionDomain). If your code is not using protection domains, you could remove the protection domain handling from ClassLoaderm saving you another Hashtable, and associated get/put calls. > How difficult > would it be to further optimize > kaffe/kaffevm/methodClass.c:processClass() for > performance? Tim Stack has 'lazified' class loading for JanosVM, and that might be helpful in your case. If you want to help out with the merge, get in touch with Tim. > Is anyone out there actively working on a port of > the JIT3 engine for > Arm Linux? I'm not aware of anyone. Peter Naulls is working on a port to RISC OS, though, and that's going to involve working on the jitter, sooner or later. Maybe you could work on it together? If you want to go ahead, there is a bit of jit3 code in the pocketlinux tree here http://www.kaffe.org/cgi-bin/viewcvs.cgi/pocketlinux/XOE_1.0/src/kaffe-all/src/config/arm/ it would be very helpful if you could take a look at the arm code and see what can be merged back into the kaffe.org tree. cheers, dalibor topic __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
