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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
