Code cleanup, regression testing and benchmarks

This week was mostly doing boring cleanup work. Tried to get the GNU Classpath native C code base -ansi -pedantic clean and turned on -Wall. Hopefully we can even add -Werror soon. Made sure that everything works well with gcc-2.95, gcc296 (yuck) and gcc 3.x, with and without -O2. Seems we are in decent shape now.

People really need to take more care about the Mauve regression testsuite. There were some nasty regressions which came with all the new code contributions. Faster development is good, but it shouldn’t cause regression test failures. We are lucky that Mauve is so big now that it catches most problems early. One of the problems it seems is that everybody is using a different runtime environment to test GNU Classpath against mauve and that we don’t have a list of canonical good test results.

Stephen Crawley fixed the Unicode tests in Mauve. This made for a fun little micro-benchmark. natively compiling programs with GNU gcj is very, very fast. But Kaffe OpenVM doesn’t do bad using JIT v3, but is still about two times slower. IKVM.NET+mono was number three, but surprisingly slower then kaffe (again about two times). Benchmarks that I did last year showed it being only a bit slower then kaffe then. Probably this particular micro-benchmark was not ideal for ikvm/mono. And I still have to try out the ahead of time compile support which will at least reduce the overhead a lot. Interesting enough Jikes RVM was almost as fast as IKVM+Mono and I only had a prototype build. Now that jrvm can be build completely with free tools (it needs kaffe for bootstrapping) I really need to get that development build going again. Only thing stopping me is the two and a half hour bootstrap process. (BTW, please don’t take this benchmark to serious, it is a micro-benchmark for one very specialized, small and repetitive task, so don’t take the numbers to serious. And see the GNU Classpath mailinglist for responses from the various free runtime hackers. It is great to see so much competition in this area!)

All in all I feel good about the progress we are making and the rapid growth of GNU Classpath and the projects around it. But on the other hand there is so much going on that nobody seems to have time to respond to all the email on the list and take care of new people wanting to help. Sorry, if I haven’t responded to email about the project yet. Feel free to send me a reminder email.

Growing pains

It seems that we get more and more people wanting to help out with GNU Classpath. Which is very, very nice. But that also means explaining our hacking customs again and again. So, I finally went through the email archive of the last couple of months and added sections on needed tools and libraries, code conventions, hacking on the code, writing ChangeLog, working with other people/mailinglists, CVS, etc to the GNU Classpath Hacker’s Guide. Hope that helps new people fit in faster with the old-hackers who sometimes have known each other for years.

One email that probably deserves to be turned into a guide of its own is GNU Classpath - How to use it. It describes how to get the last 0.08 release working out of the box. And with the latest release of JamVM (1.1.2) you don’t need any patches any more to get it working even with GNU Classpath from CVS. Currently investigating how well other VMs work out of the box. I tested that Kissme from CVS works out of the box with GNU Classpath from CVS. Next up is Jikes RVM.