Jikes RVM


I’ve been away for pretty much all of last week, attending a UK GRADSchool in Bournemouth, so there’s not been much action on the Free Java front. However, SoC officially started for real on the bank holiday (28th), so expect things to heat up from here on in. I’m still chewing over the JikesRVM build process, which managed to stall my machine the other night!

The good news is that the apt problem looks to be resolved. I’ve succeeded in splitting out javac and apt from the OpenJDK (although actually the javac is still the separate one from earlier, as I was having problems with the newer version) and can now build them using some autoconf jiggery-pokery. Which means I now have an apt ‘binary’ or actually a shell script that invokes cacao with the appropriate com.sun.tools.apt.Main wizardry. Probably should try creating a native binary with gcj at some point as well. Unless I missed it, JikesRVM is yet to hit this in the build process, but it is building the appropriate classes now, having found them in my little fake tools.jar. So things are looking brighter.

Hopefully some actual dev work soon… ;)

So I’ve been playing around with the OpenJDK source code drop over the last week, in addition to still trying to build JikesRVM and doing odd bits of gjdoc maintainer stuff (Michael Koch is packaging the newest version for Debian). Unfortunately, I’ve not yet managed to build it without the binary blobs, which I don’t want to even have to download (in the belief that if I do that, I may as well just download a proprietary JDK). The build system relies heavily on an existing JDK and a lot of environment variables… oddly makes me miss the autotools!

My discoveries so far have lead me to find that the full build (hotspot+the j2se classes) won’t build without an existing tools.jar, of which Classpath does not have a full implementation (it wants com.sun.jdi, whatever that is). Of course, this stuff is in the tree as well (but the hotspot build doesn’t seem to know that). Hacking things to make hotspot use these classes lead to the revelation that it actually wants an older version; it tries to do a 1.4 compile, while the versions in the tree use 1.5 features such as generics.

Giving up on Hotspot and trying a j2se_only build gave more interesting results (seeing the build pull out bits of Classpath, believing them to be from the Sun JDK was fun), but again stalled because it wanted a libjvm.so from Hotspot. Assuming that it would be more difficult to remove this dependency than those in the full build (as I guess the classes are closely tied to Hotspot as their VM), I went back to that and tried to pull out the tools so they can be built separately. This has other uses, in so far as it would, for one, give me an apt I could use to build JikesRVM :) Javadoc and appletviewer also seem to be in there. I’ve since been plodding through a dependency hell which sees me slowly pulling more and more of the JDK into my newly created ‘tools’ directory. javax.script, javax.xml.bind and some management code are an example of the larger stuff it needs that Classpath doesn’t yet have.

This also gave me a patch for Classpath (fixing the RMI classes to use generics so rmic could build) and I have had apt at least give me its help output. More troubling is that I can’t find some stuff — ‘Version’ and ‘JDWP’ classes seem to be proving elusive. If anyone can shed any light on that, it would be much appreciated. In the meantime, hopefully the CP teams ‘iced tea’ plans will come to fruition and we can work on the code while the legal guys sort out a wonderful shared community between OpenJDK and Classpath.

_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_

So I finally got some time to hack some Classpath code again this bank holiday weekend, and ended up feeling like I got nowhere, running into bugs and annoying problems at each turn.

Me and JikesRVM are still fighting; I haven’t had a successful build as yet. After working round the apt problem (by moving the offending files out the way and commenting out the build rule, hehe), I proceeded to watch it download ecj (after having ignored my native version earlier). This ran into problems, which I later found were down to my own stupidity. I hadn’t installed the optional ant tasks as required. That fixed, I ran into a fun issue with its Classpath download. It decided to try and ungzip it twice, so tar complained and stopped the build. Something is being clever along the way and decompressing the gzip before it reaches tar I guess.

That fixed (by again hacking the build files), I realised that the file Ian kindly gave me (the one generated by the apt tool) had got mangled in downloading. Leastways, it didn’t look like any Java file I’d ever seen before. To cap it all, I then updated and that broke the build even earlier. Hopefully, that will be fixed soon.

Returning to Classpath itself, I noticed that the Mauve runs were coming up with a ridiculous number of errors, so decided to investigate. Updating, I found I couldn’t even build. The new gtkpeer.c file wonderfully assumes that the system is 32-bit. Good job I have -Werror on or I would be experiencing some nice random segfaults next time I use the GUI stuff. A couple of #ifdefs later and it was fixed.

I then proceeding to uncover the root of the test problems — there had to be some common problem, given that it was a fairly mixed bunch of tests. Turns out the build was no longer including the locale information. I’m quite amazed no-one had spotted this earlier. It was soon fixed by correcting the new find invocation in lib/Makefile.am.

So all in all, didn’t get very far but at least thinks seem to work again…

We now have two FOSS 1.5-capable compilers: ecj and the openjdk version of Sun’s javac. Both clearly have parsers for this version of the language, which got me thinking as to whether we should simply depend on one or the other (maybe even both) to provide parsing for gjdoc. I’ve looked at the OpenJDK code so far, and this seems fairly feasible. I’ve yet to look at ecj. In the meantime, I’d be interested to hear people’s opinions on what they think best. Clearly using one of these is a dependency we have to introduce, but, if we switch to 1.5 source code, this will be required anyway. It also removes the dependency on the lexer/parser framework we use (name escapes me right now…). As I see it, there are four options:

  • Retain the current parser code and update it for 1.5. Given the state of this code, it’s likely to be something of a headache, and likely to remain fairly unmaintainable in the future.
  • Replace the parser with our own generated using the tool we currently just use for expression parsing. Seems a little redundant as there are already capable parsers available.
  • Depend on either ecj or OpenJDK javac for parsing.
  • Use either ecj (if feasible) or OpenJDK for parsing, depending on which is also used to compile.

Any feedback is much welcomed.

I’ve also started to look at JikesRVM for SoC and run into some issues just trying to build it. Seems that not all is Free in the JikesRVM world and I can’t even build on a Free Java stack. My first trauma was trying to get ant (now used for the build system) to find a Java compiler. I couldn’t seem to get it to talk to ecj, so I pointed it at the JAR file for OpenJDK as an apparent ‘tools.jar’. I then ran into problems a few steps in, where it tries to use apt (the annotation processing tool, not the Debian package manager — which could have been interesting…) to preprocess some code. We don’t have an equivalent in Classpath, and it appears this is deprecated anyway in 1.6, in favour of javax.annotation.processing and capabilities in javac. Changing this is something we’re just beginning to discuss on the mailing lists, but it seems to be accepted that Sun or IBM is needed to build… ick. It seems there was some Kaffe support earlier, but it has gone the way of the dodo (along with its reference in the user manual). Ian Rogers has kindly supplied me with the file that is generated by this apt stage, so maybe I can at least see what hurdle comes next… Makes me think I should have made the project ‘Liberating JikesRVM’…

_
_
_
_
_
_
_
_
_
_
_
_
_

So, last week was quite eventful. Firstly, I got accepted for Google’s Summer of Code, working on the Jikes RVM project. I’ll be continuing in much the same vein as last year’s GSoC in implementing the java.lang.management extensions. It gives me a good excuse to finally play around with Jikes RVM again. The last time I tried was several years back when I first started hacking on Classpath, and I fell a victim to its build system, never even getting a running VM out of it. The build system has since been seriously re-jigged, so this time I intend to have more success. At least this time round, I know who to talk to if I don’t…. ;) Implementing the extensions on a VM is a good way to get to know the ins and outs, as it requires some fairly deep hooks. Hopefully, I won’t cause too many ruptions in the codebase…

Other than that, I’ve been playing around with GJDoc, trying valiently to get it to eat the latest Classpath CVS source. I finally succeeded in getting a run through last night, and the results are available on my website. File your bugs in the usual place; believe me, there are plenty!

Google has kindly extended the student deadline to 5pm PST on the 26th of March (which is 12am on the Tuesday, in UTC). Even so, this time is steadily approaching, so if you’re thinking of submitting an application (or several) for this year, you need to do so about now. Last night, I submitted a proposal for implementing the JMX stack on Jikes RVM, which should be an interesting task, combining my existing knowledge of this area with the new challenges of a Java-based VM that I’ve been meaning to play with for a while now.

I’ve also started pulling the FOSDEM movies from my camera, mainly because I was forced to as I needed the tape to film a lecture. I’m planning to encode in Ogg Theora/Vorbis in a range of sizes and also encode an MPEG-2 version to store on DVD (the originals are too big to keep). The first results of this can be seen

Still haven’t got round to looking at the stuff I captured at FOSDEM, and surprisingly it’s already over a week ago — how time flies. There are a few pictures, but I left most of this to Mario and Steph as they were much more well prepared and equipped than I. What I do have is video of the Runtime Rumble and a couple of the Sun talks (IIRC). I need to work out where I can dump multigigabytes worth of DV before anything else; I took two tapes full in all.

What’s been occupying my thoughts so far this week is the imminent start of Google’s Summer of Code for 2007. It starts quite a bit earlier this year (student deadline of March 24th), and with all the Sun kerfuffle, it’s a little more difficult to choose a project than I expected at the end of last year’s SoC. I don’t want to put in a proposal for something that might get shipwrecked by any imminent arrivals of Free Sun code…

I raised the matter on #classpath today, and got some good feedback. There are plenty of tasks on underlying stuff (rather than APIs) that I could tackle. Also, Ian Rogers from Jikes RVM and Tom Marble (Sun’s OpenJDK ambassador) mentioned that their respective projects may be acting as mentoring organisations, so there seems to be plenty of choice. Unfortunately, I can’t really make any firm decisions until the organisations are decided, which is the same time as student proposals open. Just have to be prepared I guess…

« Previous Page