[kaffe] Placing kaffe on embedded devices

[Jukka Santala]

On Thu, 6 Jun 2002, Alexander Popov wrote:

>     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

Most people working on embedded stuff probably know their situation
better, but on a guess I'd say that majority of real embedded environment
installations of a Java compatible VM would strive to eb the only real
"service" on the device. In such installations having a static build would
be preferable, and indeed, smaller. I see you already have a mention of
this, but I thoguht the situation is more common than the above suggests.
Altough, a working system is likely to require some other system utilities
(mount, fsck?) which don't have convenient Java equivalents anyway. But
this is deeper embedded engineering than the Kaffe FAQ has to deal with ;)

On the other hand, if you're goign to have several different binaries on
the system, the notion of savings on size holds. However, Kaffe's
build-scripts already give you some control over what is linked
statically; static-linking the JNI code etc. you're going to use makes
good sense, unless you're looking forward to simple plug-in
replacements/upgrades in future. Still there's usually no reason you
couldn't replace the whole VM, as most changes would require anyway.

>        My experience shows that on systems with slower CPUs the intrp
> engine is faster than jit.

It tends to depend on what you're doing. For simple, calculation-intensive
applications any kind of JIT tends to be an advantage. But there are many
larger, itneractive application models with "throw-away classes" where I
can see intrp having definite advantages. It's a shame there isn't HotSpot
style functionality yet in the tree, but I'd expect these kinds of
optimizations become available soon after 1.0.7 is released.

> You can compile the classes that will be included in the rt.jar archive
> without debugging.

Some embedded systems also use compressed filesystems (Cramfs, JFFS2 for
example). The jar files build with Kaffe are automatically compressed, but
if placed on a compressed filesystem, this'll just hurt things.
Significant savings in speed, memory and storage size can be attained by
using un-compressed jar files on a compressed filesystem. Alternatively,
if speed is of utmost importance, you might want to leave the jar-files
totally uncompressed, or even unpacked in the file-system. Which one of
these solutions work best for each installation is a process of trial and
error. These tricks ofcourse apply also to the application jar's.


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

I haven't tried it out right now, but strippign libraries is usually a bad
idea. You want to use something like --strip-all for binaries and
--strip-debug only for libraries. But as usual, you have to try what works
best for you - your platform, and your needs. Obiviously if you're going
to be debugging things, stripping isn't too good idea.

> 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

The most useful optimization for embedded systems is probably -Os, since
the speed-optimizations (loop unrolling etc.) tend to frequently increase
code size, while space tends to be at premium on embedded systems. Also
remember that the Kaffe build optimizations don't touch the "meat" of you
application, the Java code and libraries, especially if you're JIT:ing
everything. (It will, however, affect JIT compilation, which is likely to
be takign significant amount of time on your system). Optimizing system
libraries is probably beyond the scope of a Kaffe embedded document, too,
but it might still be worth mentioning that statically linking well
optimized libraries built for the specific platform might be more useful.

Ofcourse, most of those comments aren't in format suitable for the FAQ,
but there's probably going to be some other changes too...

 -Jukka Santala