[kaffe] Kaffe for Arm-Linux

[Dalibor Topic]

Hi Jared,

sorry for the long delay, girlfriend trouble.

--- "Boone, Jared" <Jared.Boone at digicont.ch> 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