[kaffe] The trouble with Klasses.jar

Dalibor Topic robilad at yahoo.com
Tue May 28 15:07:02 PDT 2002

Hi jukka,

--- Jukka Santala <jsantala at tml.hut.fi> wrote:
> On Tue, 28 May 2002, Dalibor Topic wrote:
> > A regular source of bug reports seems to be the
> state
> > of Klasses.jar: it is usually a few patches behind
> the
> > source code. You are probably wondering why
> > Klasses.jar is not updated more regularly.
> Well, I'll second this motion to make Klasses.jar
> built by default. I was
> goign to suggest that myself, in fact, but you got
> there before. As it's
> really quick build anyway, it doesn't matter all
> that much.

the buld time using kaffe's kjc is around a minute on
my p3 500 mhz running linux and jit3, and somewhat (~
10 minutes) slower on my cyrix p200+. Acceptable for
me, I don't know about others, but I'd like to hear
about it :)

> The thought of having different versions of
> Klasses.jar as well is
> interesting, but we have to remember that due to JNI
> and other
> dependencies, the Klasses.jars ar eusually very
> VM-build specific, and for
> the most advantages the native code included with
> Kaffe also often needs
> to be modified or selectively included.

I though we could keep all of them in sync with the
automatically generated one. Unfortunately, kaffe
doesn't seem to like klasses.jar after its been
processed by either jopt nor jarg, and the optimizer
called bloat seems to have some issues, too (beside
being rather slow in comarison with jopt and jarg).
I'll try to generate a klasses.kar with soot and see
if that one survives my tests.

> Despite this, just getting Klasses.jar automatically
> up to date with the
> build is enough reason to implement this. Stripping
> Klasses.jar down to
> minimum needed for new compile may be easier said
> than done, though; but
> it's sufficient to just include a default build of
> the whole classlib
> that's recent enough to work. Maybe there's reason

Recent enough seems to depend on the patches being
checked in: I think that as soon as some code patches
the C libs, we need an updated klasses.jar. What other
sorts of dependencies exist between klasses.jar and
the rest of the VM that would make recompilation of
klasses.jar necessary ?

> to archive this
> separately in case the primary Klasses.jar gets
> messed up due to adverse
> change, but I'd recommend against making them
> separately downloadable, as
> matching VM (JNI functions) and Klasses.jar versions
> would be a pain and
> probably even larger source of (frivolious) bug
> reports.

the optimized versions should be for testing purposes
only: It is hard enough to trace back bugs to jikes or
kjc, I can only imagine how ugly it would get if you
had to fight your way through obfuscated method names
to verify that the bug is in the optimizer ;) 


dalibor topic

Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

More information about the kaffe mailing list