[kaffe] Embedded use (Zip libs, Qt etc.)

[Dalibor Topic]

Hi Jukka,

--- Jukka Santala <jsantala@morphine.tml.hut.fi>
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