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