August 2007


We’re just about to enter the last three hours of Google’s Summer of Code 2007. Pens down (or should that be hands off keyboard…?) is at 7pm UTC today. With respect to my work on JikesRVM, things seemed to have gone relatively well. Last night, I completed the first bash at the threading bean (some methods are implemented, a few are still stubs), so my branch now includes an implementation of all the VM interfaces. I feel the task has been pretty successful; I’d say I know my way around the code base pretty well now and I can see how the few things that are left could be implemented. Those that are left over will take longer, mainly because they involve capturing data which isn’t captured at present. This means we need to insert appropriate hooks into the code base in a careful way so that performance doesn’t degrade too much.

I think communication could have been a little better, but I’m to blame for that a lot. Unfortunately, we PhD students may be eligible for SoC but I don’t think we’re that well suited because we can’t devote 100% of our time to it. Had I had more time to give, I no doubt would have achieved more and interacted more with the community than I managed to. It’s also a very different atmosphere, and I’m not used to working on code at the (relatively) slow pace of e-mail correspondence. One of the joys of hacking on Classpath has been interacting on IRC with my fellow developers and the camaraderie that ensues there. With e-mail, there’s always a feeling that the response you received didn’t quite achieve what you want and now you have to go through the whole rigmarole again of sending and then waiting for someone to check and respond.

Another advantage of my work has been that JikesRVM can now be built on a Free stack again. That took some work, and sidetracked me quite a bit, but I think it was worth it. I still want to try getting the thing self-hosting, but I believe that should be fairly trivial. The main thing lacking at present is rvm’s support for acting like a ‘java’ clone. It lacks some options to do with modifying the bootclasspath, but I can see how they can be implemented.

The interesting bit to come will be merging my changes on to the main branch and hopefully working on there in future. I’m still not sure how that will work, or what hurdles I’ll have to jump through. I’ll guess I’ll find out in the days to come. I’ve really enjoyed working on the project and would like to continue contributing.

How OpenJDK Can Become GNU Classpath

Strange heading I’ll admit, but this is something I hinted at a little above and in previous blogs. It’s one thing to release a blob of source code as FOSS, and that takes a lot of work. Again, well done to Sun for what must have been a huge task with about 6 million lines of code. But making it into a FOSS project is a completely different ball game; just ask Apple ;)

Some rather cynical folks could say that Sun have already achieved their goal; the release of a GPLed version of Java means these freaky GNU hippies can go off and play with that somewhere and not compete anymore. However I feel this really is a positive move by Sun and that they do intend to turn Java into a true collaborative development. I do think there are a number of steps that need to be done to achieve this though:

  1. The code base needs to be writable; I know this is in the works, the sooner we have an active Mercurial repository rather than a read-only subversion one, the better.
  2. External developers need to be able to contribute to this code base through an open process which encourages public development and (fairly) rapid feedback. Classpath has recently had a very quick patch turnaround, but admittedly things were also getting a bit laissez-faire.
  3. The Sun people then need to work in the open with external contributors, so we can work together and not against each other. The Classpath folks have already done some astonishing things from getting Freetype working independently to getting the OpenJDK onto PPC, Alpha and S/390 (via CACAO). If we all worked together, things would be even better.
  4. There need to be some clear goals. You won’t get many contributors if you expect them to just rattle around a messy bug database. There need to be some clearer tasks to work on, with some low-hanging fruit to get people started. This also means having the JSRs not behind horrible licenses…
  5. Most importantly, let’s have *FUN*!

It’s been a while since I last blogged and I’ve since made quite a bit of progress. Today, I committed the last patch that gives JikesRVM support for three of the management beans. The remaining ones focus on memory and threading. For the former, I’ll need to take a more detailed look at MMTk over the next few days, while the threading bean will require me to merge my branch back with HEAD, as Ian’s made some structural changes in that area.

In the long run, it would be nice to not just implement the bean interfaces but also to provide additional information. Sun already does this; their OS bean for example contains more data than the management interface specifies. Really, anything about the VM that people want to monitor should be available through these beans.

Peter Donald has also kindly committed my patch since I last wrote. This means that the Classpath examples can be run with HEAD as well as on my local branch. Prior to this patch, the gnu.classpath namespace was blacklisted, stopping gnu.classpath.examples.* being used.

It would be nice to see another Classpath release soon, so I’m going to try and look into helping Mark out a bit this next week by running Mauve and looking for any regressions. There has been a lot less coding, but there are some important patches that should really be released. I’d also like the next release to support building JikesRVM, which means making sure my patches get in. I still have no clue how to implement hex string parsing though, and no-one else has come forward ;(

OpenJDK and CACAO

I’ve also been following twisti’s instructions on installing OpenJDK with CACAO this week. The advantage of this for me is that it means I can have OpenJDK on ppc64 :) In the process, we uncovered problems with the Math trigonometry functions. sin(0.7) seems to wrongly return 0.7 on ppc and ppc64, and some negative value on alpha. According to the reply we got on the core-libs mailing list, this is because the functions are implemented intrinsically to the VM for Math and only via fdlibm for StrictMath. Of course, gcj gives the right answer :)

twisti gave me a patch for solving a problem with ioctl on 64-bit archs over the weekend, and so I’ll be trying again with that and b17 tomorrow. Hopefully, we may then get a successful build.