Mark J. Wielaard

Benchmarking free VMs

Did some benchmarks to compare the free java like environments out there. GNU gcj is just very fast. Without even trying to use any optimization flags (just -O2) it out performs all others by a very large margin. Since it is based on the GCC: GNU Compiler Collection it is also available on a lot of platform which is very nice (although I tested only on my x86 platform).

Interesting was that IKVM.NET a free VM based on GNU Classpath and Mono was almost as fast as Kaffe OpenVM. But although they show comparable benchmark scores IKVM takes a lot more time to startup and prepare the classes compared to Kaffe. The difference was sometimes measurable in seconds! So it seems that although Mono has a good JIT it (in combination with IKVM) takes alot of time to prepare/load the code before it starts really running it.

I doubt a JIT can be made as fast and be available on so much different platforms as a Ahead of Time Compiler like gcj. So I hope that people will look more into combining byte code interpreters and just in time compilers with ahead of time compilers based on gcc. As the benchmarks show gij (the GNU Interpreter for Java which comes with gcj) is not a very fast interpreter. But when running real applications it is often amazingly efficient because it uses the gcj precompiled core classes so that any use of a library function is blindingly fast. And real applications use alot of standard library calls. Especially when the standard library is as diverse as the one that comes with gcj (libgcj which is based on Classpath and modeled after the standard java classes).

And after posting my own benchmark lots of people published other benchmarks. All linked from the Free VM Benchmarks page.

Gnome and Kaffe

Happy! Made kaffe love java-gnome again. This is nice since debugging is still easier with kaffe then with gij when you have to use traditional byte code applications. It would be nice though if java-gnome could be compiled into a native library with gcj. That way you could just use gdb to debug the application.

Snark, Gnome, GCJ

That was fun! Made a bittorrent client and tracker (Snark) in java which can be compiled with gcj to a native binary. And using the java-gnome bindings it was fairly easy to give it a Gnome GUI that integrates nicely with the rest of my desktop.

The best thing is that this kind of development can now be done using standard Debian (unstable) packages. Point your apt-get or aptitude at jikes, gcj-3.3, gij-3.3, libgnome0-java and off you go developing some nice Gnome desktop things.

More Eclipse

Slashdot published a story about Eclipse running on our free java platform. But I missed all the fun because I was out of town. We got more then 25.000 “visits”, 150.000 hits and 10GB of data traffic. Ouch. But now a lot more people know about this milestone :)

Jeroen Frijters took the latest sources from GNU Classpath and made them work with his IKVM.NET. Eclipse running on .NET, Wow! Now if someone makes sure that IKVM.NET works on DotGNU Portable.NET or Mono we would have a very nice bridge between the free java and .net worlds. Fun, fun, fun!

In a way it is to sad that there will be a releases soon of GNU Classpath and GNU gcj. There is so much to do before we release. But secretly I just want to work on getting Eclipse working even better. Choices, choices…

Free Eclipse!

The last couple of days have been really nice. This weekend two of my friends, Vincent Partington and Erwin Bolwidt come over for a weekend of free software hacking. They were both really enthusiastic about Eclipse for developing in java. Since Tom tromey already mentioned that he got Eclipse starting up once using GNU gcj I thought it was a cool idea to try to get Eclipse running some more. I was really surprised how well it already ran and that weekend we came up with a couple of patches that made most of Eclipse actually run. Then on Monday Anthony Green supplied a patch to get the Garbage collector working and now a couple of days (and patches) later a non-trivial amount of Eclipse seems to work (although slow and with occasional lockups, so it isn’t actually usable yet for real work).

It will still be very much work to make Eclipse really usable on top of GNU gcj and GNU Classpath but I do see light at the end of the tunnel. I am really happy that the years of work of the GNU Classpath and gcj hackers have produced a free java platform that is now finally usable for such big projects (Fun trivia fact: When Eclipse wants to show its help pages it starts up a Tomcat server and a Mozilla browser to view the JSP pages. And this works under gij!).

I made a page with instructions to run Eclipse with gij and some screenshots (which show how nicely Eclipse looks – since it uses GTK+ widgets). Please look at it if you want to help us make Eclipse more usable on gcj (or just for the very nice code completion screenshot).

GCJ 3.3

Did an a lot of testing and rebuilding of the GCC: GNU Compiler Collection. That is such a big project and my machine is so slow… But it seems that at least GNU gcj 3.3 is already in good shape. Made lists of Mauve testresult status and Other testsuite failures. Two months will be more then enough to kill these last bugs. But we can always use more testers. So if you have a free software java project please try out a GCC 3.3 snapshot so we can make sure that when we release it works for your project.

Jikes RVM 2.2.0

The Jikes Research Virtual Machine is a free virtual machine written in java that is self-hosting!
Version 2.2.0 now mostly uses the GNU Classpath class libraries. And they are optimistic that release 2.2.1 of Jikes RVM will be based entirely on the GNU Classpath libraries. Yeah! Another happy customer.

GNU Classpath API doc

It seems we now have API doc for the core class libraries online. It looks nice. We need a lot more documentation, but some of these docs are already very useful when writing java programs. Please check it out and if you find something missing then please write something for it. Documentation patches are always welcome. The documentation was produced with gjdoc which is not completely finished, but as you can see already very capable of producing nice javadoc. (It actually produces XML files that are later transformed with xsltproc to the actual HTML.)

GCC 3.3

Yeah! GCC: GNU Compiler Collection has branched for 3.3. I am really excited since at least GNU gcj 3.3 is a big improvement over 3.2. And it opens the door for exciting new development for 3.4. GNU Classpath has implementations of java.awt, java.util.prefs and java.util.logging that are all waiting to be imported into the libgcj CVS tree. I have some ideas for sharing more of java.lang, java.io and java.net between Classpath and libgcj. And it will be fun to experiment with the new stack walking code that Andrew Haley made. But it also means a lot of extra work since a lot of people will now suddenly realize that they have to actually test this thing and they will find bugs that the regular developers thought didn’t exist anymore. And all bug fixes now have to be tested against two versions. Finding disk space for an extra build of gcc (almost 1 Gig when you have a source, build and install, and that is a build for only the C, C++ and Java compilers and libraries) was also fun (why-o-why did I ever think that having 6 partitions on each disk would be smart…) I also had to update my autobuilder to test both mainline and the 3.3 branch. Interesting 2 months ahead anyway.

GNU Crypto

GNU Crypto has fastly grown to a full blown crypto library for java. It is now also a java security provider. So we have been solving all the bugs in GNU Classpath that prevented security providers to work. And it seems we are now almost there. And GNU gcj produces really fast crypto code since it is able to do some nice optimizations when it compiles to native code as an ahead of time compiler. This really shows the power of gcj. Being build on top of the GCC: GNU Compiler Collection it can produce good code for a lot of processors (x86, mips, powerpc, alpha, ia64, s390, arm, etc.) It is not that hard to create a portable java bytecode interpreter that would run on all those platforms, but producing a fast interpreter for those platforms would be a lot of work. But when you compile to native code with gcj you get it for free!

If all goes well we will have a very nice and fast crypto addition to the GNU java platform next year.

More Progress

Anthony Green is my hero! He is doing what robilad was suggesting. If the mountain doesn’t come to the compiler, you bring the compiler to the mountain. He setup rhug a collection of java packages built with gcj. The current list of packages is nice and long. He now also made rhug RPMS available.

Some is creating a Graphical Configuration-Tool for Wine: “Its written in Java, is compiled to a native-Linux program via gcj and uses java-gtk as toolkit.” Nice, nice, nice.

Classpath/libgcj merging

Merged the GNU Classpath gnu.java.security.provider package with libgcj. And merged to GNU gcj javax.transaction package with Classpath. Which reminds me to finish the merging of javax.naming (JNDI) package that libgcj has. But I really want to create some documentation for it and it is a non-trivial package.

Progress

Did I complain about not enough progress in the free java community? I probably spoke to soon :)

Today I (with help from Andrew Haley) added a patch to GNU gcj for StackTraceElement support. Which means that we now have usefull exception chaining and that you can get at some nice meta information when your program throws exceptions.

Jeroen Frijters is building a JVM for .NET using GNU Classpath. He even supplies us with usefull bug reports.

The Jikes compiler has a new release (1.16) which adds support for assertions and kills some nasty bugs.

And since I had trouble getting ORP working with a recent Classpath CVS tree I tried Kissme which works out of the box with Classpath from CVS. I did find some bugs but it didn’t do that bad on the Mauve testsuite.