[kaffe] Placing kaffe on embedded devices

[Jukka Santala]

On Fri, 7 Jun 2002, Alexander Popov wrote:
> Ok. Do you think I should remove the Configuring section?

Nah, probably not. Just with the detail it already has, it's probably
worth mentioning that best solution may be to link dynamically to re-used,
non-performance critical libraries, and statically to rest (JNI code in
particular). A reference to FAQ.libtool for the overall static/dynamic
philosophy, and FAQ.staticnative for how to make your own native code
static might be useful.

> In certain cases I've seen jffs2 compress jar files to about 70% of 
> their original size, so I wanted to check that out before writing about 
> it...

One can create uncompressed jar-files with -c0f. The jar-file compression
is indeed more efficient than jffs2, because jffs2 compresses each page
invidually (typically 4k chunks) specifically to allow easy decompression
on limited resource devices. However, applying the same compression twice
as jffs2 + compressed jar usually does, is always a loss. So while I
wouldn't take position on whether jffs2 or jar compression is better, as
that depends on the specific application, they should not be used at the
same time.

Note: Technically jffs2 compression could be turned off for pre-compressed
files, on case-by-case basis, or the compression algorithm could be
replaced with one more efficient on class/jar-files; but that's beyond the
scope of the document ;)

Ps. Kaffe "OpenVM" presently requires X-Windows to be usable with GUI,
which I guess leads to a full-blown OS being reasonable. With the "Custom
Edition" and if/when framebuffer style GUI's are proted over to the
Kaffe.org edition, I suspect stand-alone installations might become more
common. Framebuffer with static linking to uClib or similiar will
certainly allow much lower-end platforms to be supported. This would make
Kaffe viable for present-day phones, wrist-computers etc.

> About the speed It's sure better not to use jar files at all - I agree 
> with that...

Actually, I didn't mean to say that. It depends a lot on the filesystem
etc. In many cases a full-fledged filesystem can be much slower than just
referring to a jar-file index/contents, this is especially true for
Windows style systems. In addition the embedded devices often have limited
IO bus/chips/support, leading to low transfer-speeds, and whole jar-file
compression might beat reading through filesystem meta-data even on a
compressed filesystem.

So I think the final resolution is that you need t read real-world tests
with real-world data in all cases; but its good to be aware of the
alternatives, as well as the fact that compressed jar and compressed
filesystems don't mix too well. The latter could be a sticking point even
on a fairly uncritical application. Ofcourse, all the present wisdom
gathered on these is likely to fly upside-down with the jar-file
index/caching modifications etc. ;)

I think in the end it's most useful for such a document to list some of
the things you can do (compress, extract or package specific jar-files,
compile static, dynamic etc.) and what they affect / are affected by
without too big value judgements, except for such details where there
exists more or less complete consensus - such as static builds if VM is
the only real service on the device, and for non-reusable/reused code, and
avoiding double-compression.

 -Jukka Santala