[kaffe] Placing kaffe on embedded devices

[Jim Pick]

Thanks!  It's in the CVS version now.  If you've got any updates, send
them to me, and I'll commit 'em.

Cheers,

 - Jim

On Thu, 2002-06-06 at 08:42, Alexander Popov wrote:
> 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
> ----
> 

> 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...
>