[kaffe] Placing kaffe on embedded devices
jim at kaffe.org
Sun Jul 7 12:32:47 PDT 2002
Thanks! It's in the CVS version now. If you've got any updates, send
them to me, and I'll commit 'em.
On Thu, 2002-06-06 at 08:42, Alexander Popov wrote:
> I wrote the FAQ.embedded.
> And since I'm not a Kaffe expert, any comments and suggestions will be
> wellcome... :)
> Alexander Popov
> Team Leader RTOS&JVM
> ProSyst Bulgaria
> s_popov at prosyst.bg
> s_popov at prosyst.com
> mobile: +35987663193
> icq: 29207350
> FAQ for using Kaffe on embedded systems
> Written by Alexander Popov (s_popov at 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):
> 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:
> 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.
> 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...
More information about the kaffe