Hi Jukka, --- Jukka Santala <[EMAIL PROTECTED]> wrote: > I'd like to remind that a large amount of itnerest > to Kaffe comes from the > perspective of use on embedded, reduced resource and > otherwise exotic > systems. On the desktop scene for example, Kaffe can > hardly compete with > Sun, and even the free-software community seems to > be edging to turn more > towards Wonka and GCC than Kaffe. That having been > said, Pocketlinux' > Kaffe was and still is one of the most complete and > best embedded > solutions. For that reason I'd like to see > Kaffe.org's version try to > reach its full potential in this avenue.
I couldn't agree more. Wonka and GCJ have been making great progress, and I hope they will continue to do so. Just like kissme, and a few other alternative VMs. It's good to see a healthy ecosystem is out there. One way of catching up is to fill in the gaps in the class library with the library code from GNU Classpath project, GNU JAXP, and soon Tritonus.org. The other way of catching up is to merge in interesting bits from the pocketlinux tree into kaffe.org tree, including their platform ports and various AWT backends. Kevin and Kiyo have looked at the platform specific bits for mips & superh, and produced patches that improve/merge in the good bits of the pocketlinux implementation. Thanks for doing that! Unfortunately, motivating people to work on merging in bits from pocketlinux AWT implementation proved to be a hard thing, i.e. noone volunteered to do it, although I pointed some people to it. I think that's a sad thing, and I'll keep pointing people to the pocketlinux AWT sources in kaffe's CVS untill someone comes along willing to merge them in. Maybe someone else can come up with a better approach than mine to motivate people to do the work. It would be great if we could get more patches from embedded users of kaffe, as patches shape the direction of a project significantly. I've fixed the ARM interpreter to be able to build again on ARM in September, despite not knowing much about the ARM platform and not having access to ARM platforms at all (except through handhelds.org). It's not that hard, so if anyone has some interest in improving the ARM port, please go ahead: a jit3 is waiting for you ;) One thing that is hard for embedded porters is cross-compiling. With the new build system, it has become more complicated. If someone could write up a FAQ.cross-compiling document, that would greatly increase the chances of seeing kaffe run on the Zaurus, for example. The developer doing the port at the moment has trouble getting it to work without any documentation how to cross-compile kaffe, and pointing him to a few mails in the archives didn't really help. So if anyone have worked out a step-by-step way how to cross-compile current versions of kaffe for embedded platforms, please consider submitting a FAQ document, as that question gets asked quite a lot. > This is mostly a generic musing, since I haven't had > time to run actual > performance/resource comparisions lately. However, > the notion that the > more of Kaffe is written in Java, the better, is one > I have some trouble > with. I can understand the desire to unify > codebase, but the effects on > performance and resource use quoted here make me > question if it's worth it > for embedded systems where every byte counts. So, I > suppose, make that a > vote for considering the performance of the old > implementation one of the > things implemented better in the old version. As > usual, I'd be happy with > a compile-time selection between the two, altough I > realize maintaining > multiple versions isn't easy either. When I'm talking about writing more of kaffe in Java, I mean moving the native code from the class libraries to pure java code where possible and a good enough reason exists. Java code is easier to debug (at least for me), let's us do more sophisticated optimizations (ZipFile on-demand caching in latest Classpath code) without having to handle the ugly aspects of C portability, and so on. For example, I can't tell why the native zip library code breaks on Cygwin when it apparently works on other platforms. I can't debug it without crashing that platform's gdb. The only way I could find about the source of that bug at all was by using kaffe's own debugging facilties. The pure java version, though, works (except for the DosTimeVerify problem), and lets us pass about 80 regression test cases that used to fail on that platform. There may be performance problems associated with that approach, and I'd like to hear about them. If people could for example run the Ashes benchmarks once a week on their favorite platform and post the results to the mailing list, we'd have hard data to evaluate the performance effects of such native-to-java changes. Every platform is obviously different and may react in different, unpredictable ways to changes. I am hoping to get feedback from embedded users like yourself, hopefully with some numbers, because such changes can affect environments with limited resources harder than desktops. I'd appreciate performance data on benchmarks that are of importance to embedded systems, whichever they are. I'm open to suggestions. Mine is to compile kaffe's class library ;) I'm compiling latest kaffe, and 1.0.7 on the handhelds.org ipaqs to have some numbers to play with. On the other hand, ipaqs are not exactly low on resources: they have more than double the memory of my i386-cygwin test box, and more bogo-mips ;) > And yes, this was posted as a generic embedded use > note, because I also > noted that Qt Embedded is now being recommended, > with porting FGL etc. > over apparently no longer considered. Again, real > impact is hard to > measure withotu actually doing the port, but it > would seem that Qt > Embedded pulls in along a lot of stuff that just > isn't needed for basic > Kaffe operation. In this case I suppose Qt Embedded > might do if you're > willing to forego it not being free software, but in > general I'd like to > see embedded/restricted environment use taken more > into consideration, or > a statement to the effect that it isn't a design > objective for Kaffe.org's > version if that's the case. I would like to see all of the AWT backends from PocketLinux go into the kaffe.org tree, but noone has volunteered and posted any patches yet. On the other hand, someone has submitted a Qt backend, someone else a Qt2 backport patch, and there is a lot of interest in making it work/working with it. I merged the code in because it was finally possible to do so using the autoqt macros without having to significantly change kaffe's build process. Qt Embedded is supposed to be free software, as in GPL-licensed according to http://www.trolltech.com/developer/faqs/gplembedded.html . There also is a GPL-licensed version of Qt, according to http://www.trolltech.com/developer/download/qt-x11.html . Can we agree that GPL is a GPL-compatible free software license ? :) I've pointed people to the merged-in AWT backend for Qt because it is already merged in, that's all. I'd be happy to point people to other AWT backends once they are merged in, and I'm still asking people looking for framebuffer based AWT backends to consider doing the work to merge them in. On the other hand, if they are just interested in getting something to work quickly, then fixing the Qt port's weeknesses should be easier than merging in another backend from scratch. I might be plain wrong on that one, though, because noone has ever attempted to merge in an AWT backend from pocketlinux AFAIK ;) Being a free sofware project, kaffe will probably go where its users, developers, bug reports and patches take it. Jim has posted a list of things he'd like to see in 1.1.0 [1], and a few things on the list have been addressed, while a few others have not, among them prominently the PocketLinux merge. Being small and fast is one of the design goals in my own code. I haven't been writing much of it lately, just merging stuff, though. If something is inefficient in the code imported from GNU Classpath, for example, I'm sure the Classpath developers would like to hear about it. After all, GCJ uses almost the same code base as GNU Classpath in general, so if GCJ gains momentum on embedded systems because of its efficiency, than it would be a performance issue inside the kaffe VM core or our own class library if kaffe handled the same code much less efficiently. And that's something I'd like to hear about, too. Speaking of the class library, maybe we could provide --without-RMI, --without-AWT and --without-JAXP configuration options for systems that don't need to have these parts of the class library, for example, to reduce its size somewhat. Does anyone feel like it's a good idea and worth implementing it? Anyway, if anyone wants to encourage me to devote my kaffe hacking time to embedded systems and send me an embedded linux device for Christmas, feel free to ask for my postal address ;) best regards, dalibor topic [1] http://www.kaffe.org/pipermail/kaffe/2002-July/008490.html __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe