[kaffe] Placing kaffe on embedded devices

Alexander Popov s_popov@prosyst.bg
Thu, 06 Jun 2002 16:42:59 +0100


This is a multi-part message in MIME format.
--------------040906070701010609060901
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I wrote the FAQ.embedded.
And since I'm not a Kaffe expert, any comments and suggestions will be 
wellcome... :)

Regards,

-- 
Alexander Popov
Team Leader RTOS&JVM
ProSyst Bulgaria
s_popov@prosyst.bg
s_popov@prosyst.com
mobile: +35987663193
icq: 29207350

--------------040906070701010609060901
Content-Type: text/plain;
 name="FAQ.embedded"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="FAQ.embedded"

FAQ for using Kaffe on embedded systems
=======================================
Written by Alexander Popov (s_popov@prosyst.bg)

This FAQ explains how to optimize the storage space needed by the Kaffe Virtual Machine on systems with
limited resources.

It describes the process for the tree structure of Kaffe's CVS from 01.06.2002...
The same thing can be applied for older versions of Kaffe (1.0.6, 1.0.5), only the location of the files
in the tree is different there.

In General
----------

Generally the storage space reduction is done by:

    - Compiling the classes with no debugging info.
    - Removing the classes not needed by your application.
    - Removing the native libraries not needed by the VM 
      after removing these classes.
    - Removing the scripts and binaries not needed on the
      embedded device.
    - Stripping all the native libraryes and binaries from 
      the debugging info.
    - Removing other parts of Kaffe (header files, jars, docs,
      development tools )

Compiling Kaffe
---------------

- Configure-ing:

     1. You must decide if you will use a static or a dynamically linked VM.
        In most cases a shared VM is the preferable scenario - it's smaller but you 
        need to be sure that you have all the libraries needed on the target device.
        In this case specify the following options to the configure script:
        
        In the case when only java based applications will run on the device and they 
        will be started directly after the kernel boots (for example instead of init)
        it is a good idea to use a static VM and no libraries on the target board.
        Pass these options to configure:
       
     2. Choose the engine.
        My experience shows that on systems with slower CPUs the intrp engine is 
        faster than jit.
        You might try both of them to see what fits your needs/device best.
        The factor here is the speed because the difference between the storage used with jit and 
        the one used with intrp is not considerable. If your target platform supports jit3 you
        may consider testing that too.

     3. Remove the profiling and debugging (at least for the final sollution):
           --disable-debug
           --disable-xprofiling
           --disable-xdebugging
           --disable-feedback
           --without-profiling
           --without-stats

        To be sure that these are applied (for example) check the gcc otptions used during the compilation
        for "-g".

     4. If you don't enable the use of pthreads you will save some storage space from the 
        libpthreads.so but if other applications will use it on the target device you might 
        enable it.      
        
     5. Disable the gcj support:
           --disable-gcj



Compiling the classes
---------------------

You can compile the classes that will be included in the rt.jar archive without debugging.
Currently (06.06.2002) the rt.jar archive is about 1054K with debugging and 916K without 
debugging info in the classes.
You can compile the classes without debugging using the compiler from SUN's or IBM's JDK 
with the -g:none option.
Go to <KAFFE_SRC>/ibraries/javalib and do:
export -n JAVA
export -n JAVAC
export -n CLASSPATH
export JAVAC="<PATH_TO_JDK>/bin/javac -g:none"
make Klasses

For more details on recompiling Klasses.jar check FAQ/FAQ.classlibrary-compile.



Stripping rt.jar
----------------

If are familiar with the classes needed by your application you can remove those that
you don't need from <KAFFE>/jre/lib/rt.jar.
For example:
My board doesn't have a display and I don't use awt. So I removed the java/applet, java/awt, 
kaffe/applet and kaffe/awt brunches from rt.jar.
The same way you can remove beans, security etc.

I usually remove comm.jar, microsoft.jar, pjava.jar, rmi.jar and servlet.jar too, because I either 
don't use them or have my own implementations of these classes/interfaces that are part of
my application's jars.

The whole thing saves me about 1MB from the jars only, but that depends on the application and the device.



Removing the native libs
------------------------

By removing certain classes from the jars you have no more need from certain native libraries.
Depending on your target arch these libraries are in <KAFFE>/jre/lib/<ARCH>/
Following the example above I usually remove libawt* and libmicrosoft*.



Removing the binaries
---------------------

Many of the tools that Kaffe offers are of no need on the target device.
I usually remove everithing from <KAFFE>/bin except the "kaffe" script.
The same thing should be done in <KAFFE>/jre/bin - just leave kaffe-bin and kaffe.
The two kaffe shell scripts too can be removed but then you must take care of the
environment setup for the VM. And if you use a compressed filesystem the text files are 
not to be really considered as a storage problem.



Stripping the native binaries
-----------------------------

"strip" is a beatifull tool when you go embedded :)
So strip all the native libs that are left in <KAFFE>/jre/lib/<ARCH> and the kaffe-bin binary
in <KAFFE>/jre/bin.



Misc
----

Also you won't need the man pages, the header files and the jars in <KAFFE>/lib on the embedded device.
so just remove the folowing dirs <KAFFE>/include, <KAFFE>/lib, <KAFFE>/man.

After all these steps my arm/linux Kaffe port goes from 5292K to 1168K which is almost 5 times difference.

You can also consider using a higher optimisation level with gcc's -O option, but this is not 
safe - there are couple of people that reported problems after going to -O3...


--------------040906070701010609060901--