Hi jukka, --- Jukka Santala <[EMAIL PROTECTED]> 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 ;) cheers, dalibor topic __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
