[kaffe] Placing kaffe on embedded devices

[Alexander Popov]

Jukka Santala wrote:
> 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.

I agree with that. I'm sayng that this is the preferable scenario 
because in my practice with emb. devices so far I've seen only 3 or 4 
cases in which only the Java is used... Most of the others have a fully 
functional OS (including a set of libraries and tools using them) or the 
Java VM is part of the OS itself (which excludes Kaffe as a sollution)...
But this very much depends on the hardware and it's purpouse... I'll 
mention that in the FAQ.


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

Ok. Do you think I should remove the Configuring section?

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

Again I agree... this is why I say that everyone should make their own 
tests and decide which engine model siuts them best...

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

I though about that too... I'll add it to the FAQ, but first I wanted to 
  make some benchmarkings (with jffs2 for now) for the "real" storage 
used by the classes.
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...
About the speed It's sure better not to use jar files at all - I agree 
with that...

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

:) Thats why I said that this should be done for the final sollution - 
the development/testing process wloud be a nightmare without the 
debuging info in both the binaries and the libs...

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

Sure. I've already fixed couple of stupidities that I wrote in the first 
draft...

I'll have all these in mind. Thanks Jukka...

Regards,
>  -Jukka Santala
> 
> 
> 


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