[kaffe] need your help in optimising Kaffe

[Dalibor Topic]

Kirankumar T wrote:
> hi

Hi Kirankumar,

>            we are doing some research application  as part of it we are 
> trying to 
> optimise the kaffe JVM  .So we removed almost all the lib,doc...
> now it came to 1.5Mb 
>         to further optimise it i am thinking of removing un used user 
> define class loaders
> is it possible to remove userdefine class loaders?

I'm not sure I understand. What is a user defined class loader?

>  can i have kaffe jvm of size less than 1Mb?

In theory, I'd say yes. I've tried to cut the i386 VM down to just the 
things necessary for running HelloWorld. My installed size, after 
purging all the things that are not necessary is

topic at jbox:/tmp/classes$ /tmp/topic/current/bin/kaffe HelloWorldApp
Hello World!
topic at jbox:/tmp/classes$ du -ks /tmp/topic/current
1136    /tmp/topic/current

Using latest CVS, debian sarge, gcc 3.3.4.

A few things: this is not statically liked, so by using static linking 
for the VM, it should be possible to bring the size further down. It's 
currently not possible to disable the building of the native libraries I 
explicitely removed by hand. I could provide a set of configure options 
to do that, though. --without-native-zip, without-verfier, etc.

The native libraries needed for hello world, and their sizes:

topic at jbox:/tmp/classes$ ls -sS1 /tmp/topic/current/jre/lib/i386/
total 508
380 libkaffevm-1.1.x-cvs.so
  56 libnative-1.1.x-cvs.so
  24 libkaffegc-1.1.x-cvs.so
  16 libnio-1.1.x-cvs.so
  12 libio-1.1.x-cvs.so
   4 libnative.la
   4 libkaffevm.la
   4 libkaffegc.la
   4 libnio.la
   4 libio.la
   0 libkaffegc.so
   0 libkaffevm.so
   0 libnative.so
   0 libnio.so
   0 libio.so

All the libraries have been compiled with gcc's -Os option to opmitize 
for size. They have been stripped, too.

The largest chunk is the 380k of libkaffevm, of which the largest 
portion is in the translate function of jit3. You could further reduce 
the size of the library by chosing to use the smaller jit engine instead 
of jit3, or the even smaller interpreter engine.

By compiling the code statically, you should be able to reduce the size 
further, and get rid of most of the 0k and 4k files.

The other large chunk was the class library. I used a very simple scheme 
to create a transitive closure of java.lang.Object and the few other 
classes needed by kaffe. I went to the source directory 
libraries/javalib and then called

jikes -d /tmp/classes/ -g:none java/lang/Object.java 
java/lang/ArithmeticException.java java/lang/StackOverflowError.java 
java/io/IOException.java java/lang/OutOfMemoryError.java

which compiled just the smallest set of classes needed, and wrote them 
into /tmp/classes. Jarring the classes there resulted in a 560k rt.jar 
file. It's available at http://www.kaffe.org/~robilad/mini.jar

So, all the things taken together, I'm quite confident that you can make 
a version of kaffe that fits in under 1M and can run programs that don't 
use most parts of the class library.

As you're doing research, you may be interested in implementing a free 
software PACK200 (de)compression implementation. That would 
significantly reduce the size of jar files. Other than that, a cheap 
(but probably very slow) way to reduce the size of rt.jar would be to 
use something like tar.bz2 instead of zip. mini.jar is about half the 
size as a tar.bz2 file, but you'd need to write a separate class loader 
for that.

cheers,
dalibor topic