Jikes RVM

It seems a lot of projects and distributions are seeing new releases either now or in the very near future. This week, we had a very quiet minor release of GJDoc, the GNU Classpath equivalent to javadoc. 0.7.9 includes a few changes that were previously only available in CVS, but the main one is a small fix that allows Classpath 0.97.1 documentation to be built. Our minor .1 release for 0.97 fixed a bug where the JSR166 code was not being included in the documentation build. With this fixed, it turns out gjdoc would no longer build the documentation as java.util.concurrent.TimeUnit is a rather complicated enumeration that our hacks can’t bypass. Michael Koch, in packaging GJDoc for Debian, was kind enough to point out that having the current release of GJDoc not being able to build documentation for the current release of Classpath was a bad thing. A quick release fixed this by pushing out the fix I made for this issue back in March. Of course, you can now use javadoc for IcedTea/OpenJDK to build the documentation instead; with another Free JDK about, there’s no need to just rely on GJDoc.

I do wonder what the long term future for GJDoc should be. It only works with GNU Classpath at present through a nasty bunch of hacks which cause the parser to skip chunks of the input. It really needs a major cleanup and to be made to work properly with 1.5 code. Thomas Fitzsimmons suggested we should merge it into the GNU Classpath codebase which seems a good idea, as it means we don’t run into this same revision hole we just did. However, it is worth maintaining GJDoc at all? For me, the main features it has over the OpenJDK javadoc are in speed and the look of the output. A key feature is also that it it plays nicer with Free Software i.e. it includes an option to include the source code with syntax highlighting. You can see the output for Classpath 0.97 online.

JikesRVM is also stepping up for a new release, 2.9.3, and this will be the first to showcase the new Classpath support for a non-copying unsynchronised StringBuilder. This is designed for local method usage where the builder will be converted to an immutable String object rather than leaving the method. As a result, I’ve been rushing to get it in a releasable state, as I know there’s a nasty bug lurking in the older patches JikesRVM has been using recently. I managed to do this today after we fixed a build issue. It seems the javah in OpenJDK6 outputs differently named header files to those JikesRVM implicitly depends on. We fixed this by making this dependency explicit as it should be, but perhaps this also uncovered an OpenJDK6 bug. I’m not sure where we should be filing these yet, so I just posted to jdk6-dev.

It’s also nice to hear that Ubuntu has just shipped with IcedTea6 included. Fedora 9 will also ship early next month (May 13th) with similar support and an OpenSUSE build is in the works. It’s nice to see Java support making it into the mainstream, thanks to Sun’s recent moves to make their JDK Free Software. On the less positive side, it seems that Gentoo won’t see support for IcedTea6 anytime soon. The Java Gentoo developers seem to be on a strange mission to support only the proprietary Java solutions (pretty much an inverse of what Fedora, Ubuntu and Debian do). In porting my IcedTea6 ebuild from the Libre Java overlay to their own overlays, they seem to have decided to drop support for GCJ… I’m not even going to go into how dumb this action is, as I could be here a while. Suffice to say, I don’t see how IcedTea6 can be bootstrapped without GCJ, let alone how they expect to then build it on architectures like PPC, PPC64 and ARM, as we’ve seen happen on the OpenJDK distro mailing list. It seems a very odd move for a distribution supposedly built on compiling things from source…

It’s that time of year again! This time, I’ll hopefully be mentoring some students instead, especially after my OpenJDK Challenge proposal was accepted. :)

If you’re a prospective student for SoC 2008 and would like to work on Free Java, then please come and join us on either:

Want to find out more? Then mail classpath@gnu.org or hop into #classpath on FreeNode IRC (same network as #gsoc this year).

Well it’s now 2008 (unless you’re in the US of course) and traditionally a time to reflect upon the year just gone. Well, it’s certainly been one of movement and change in the GNU Classpath community, if also one of very little code hacking. Of course, the biggest event of the year was the release of the OpenJDK source code in May; about 95% of the JDK source code base was made available under the GPLv2, the rest both then and now being filled by binary blobs, which are slowly decreasing in number.

However, back in January 2007, we were still waiting for this to happen. As I recall, we’d just (gone through the generics merge, migrating the contents of the branch on to the main tree and over the Christmas period I added quite a lot of 1.6 code. Sun’s javac compiler was open-sourced however, as part of the November announcement, and we soon had support in GNU Classpath for building with it.

In February, GNU Classpath was again at FOSDEM and I finally attended after missing out on the last two years. It was good fun and notable for our collaboration both with the DevJam folks and the OpenJDK community (AKA Sun). Everything was very much still ifs and buts however, because I don’t think anyone knew what would really happen when the floodgates opened and the JDK was released. Of course, GNU Classpath will again be at FOSDEM this year, and apparently with even closer collaboration with OpenJDK — try and even spot a mention of GNU Classpath on those pages… Hopefully, I’ll be there again too.

The year only saw two Classpath releases, which is sort of representative of its ongoing decline I guess. 0.95 was released shortly after FOSDEM in April, a delayed and very necessary release which include the generics move and the other stuff I mention above. Getting a GNU Classpath release out the door has become more and more of a struggle over this year and, in a way, has become synonymous with a pregnant mother giving birth, as a team of developers stand round screaming ‘push’ until eventually the release emerges. Our release of 0.96 in October certainly felt like that to me anyway. On that note, congratulations to both Michael Koch and Roman Kennke who both (or should I say, their respective partners) had children this year.

May of course saw the release of the OpenJDK source code and the inevitable hordes jumping on and pulling it about took place with the same speed and haste we saw on the release of javac. This has eventually surfaced in the form of IcedTea from a number of GNU Classpath/RedHat folks, a build framework for the OpenJDK which, most importantly, serves it without the need for proprietary code (given that the current OpenJDK build has no real advantage over a proprietary JDK drop unless you want to tinker). This was produced by splicing in bits of GNU Classpath code. It’s a whole deal more easier to use than plain old OpenJDK but still not a walk in the park. This is especially true since Sun split up the build process and made parts of it depend on Ant

It’s quite sad to say, but OpenJDK is still not what we all hope it will be. Thankfully, live Mercurial repositories are now available as of December, but there are still too many walls, as I mentioned before. It’s like the JDK was something that popped out of a little black box, but now someone has taken the lid off the box so you can see the little worker ants running around inside and making it all happen. But there’s not yet anyway to get inside the box ourselves. New ants need to be able to join in the fun. We’ve already seen one of the goals I mentioned in August realised (the open repositories), and hopefully more will change in 2008. Sun’s innovation awards are both a realisation of this problem (common to both OpenJDK and many of its other open source projects, which still have a predominantly Sun ethos) and hopefully its saviour.

It smells a little like Google’s Summer of Code and indeed Tom Marble was asking myself and Mario about this on IRC. This year of course saw me tackling JikesRVM for GSoC, trying to implement the VM-level management extensions. A lot of this work was done, and following GSoC, I was made a member of the JikesRVM team. However, the patches still haven’t gone in to the mainline, due to a combination of the release process (some of these are likely to be destablising) and finding time myself to test the stuff on the main branch. This hasn’t been helped by a re-emerging problem with building JikesRVM using Classpath; this same problem plagued my initial month or so on the project when I discovered it seemed to rely on proprietary software to work…

So altogether it’s been an interesting year. Not only have I worked on both the old (continuing with GNU Classpath and also pushing out a release of GJDoc) and the new (launching the IcePick project to build the OpenJDK tools separately) over the last year, but I’ve also sadly seen the community enter something of a demise as people start to move on to other things, especially IcedTea and OpenJDK. What will 2008 hold? Maybe I’ll find myself working on OpenJDK too…

Now that SoC is finished, I’m looking at what to do next and a lot of things within the Free Java world are competing for my attention. Primarily, we need to get another Classpath release out the door as 0.95 was released in April. There have been quite a few bug fixes since then, and it would be nice to make these more widely available. Also, we plan on releasing a new version of JikesRVM pretty soon, and it really should ship with the latest Classpath. One issue that I believe should be fixed in CVS (e-mails this week seem to be saying something to the contrary) is buidling using OpenJDK’s javac. For JikesRVM, this would mean it could drop its dependency on downloading, building and using ecj. A plan for this is now on the Classpath wiki.

On the subject of JikesRVM, I’ve now been made a member of the core team and I’m working towards integrating the JMX stuff (still on the SoC branch) into the main tree. For the imminent release, I think this will just be the parts that don’t impact too heavily. There are some changes to the threading code involved that I think need to wait until post-release and more review/performance testing.

In the long run, I’d like to see Classpath being able to run JConsole, which means supporting the remote part of the JMX specification. This should hopefully mean a new blast of code into the Classpath repository which has been dormant of late. I also need to look further at IcePick, merging my work on building the Java tools (javac, javadoc, etc) with Dalibor’s SoC work for javac. There’s also more work that could be done on GJDoc, if we’re still maintaining that, and I’d like to look and see if there’s anything that I can do to contribute to OpenJDK yet (the modules stuff Dalibor mentioned to me looks interesting). Lots to do, I should file a bug request for a 48-hour day enhancement…

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 ;(


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.

Some good news. It turns out it wasn’t my build of the RVM that was buggy, but rather a case of JikesRVM being too clever for its own good. Observe the name of the class I was trying to load:


Its prefix is ‘gnu.classpath’ which is also used for some of the core classes. JikesRVM only tries to use the bootclassloader if part of the class’ full name (with package) contains one of the packages it considers to be one of the core packages. In full, these are:

private static final byte[][] bootstrapClassPrefixes =

It makes a lot of sense, but is a bit too strict. You’ll note that javax isn’t there, even though a lot of the library classes are in that package (JMX itself for one, along with Swing) and it is one of the prefixes Sun disallows being used for external classes. Why? Because lots of extensions wouldn’t work if it was.

So that line stops the Classpath examples working, and I’ll be patching it on my new JMX branch:


and submitting a patch. I’m not going to remove it completely, but instead be more specific and specify the appropriate residents of gnu.classpath that should be blocked. I’m thinking in the long run it might be nice to have this automatically generated during the build if that’s possible.

I’ve just found that it generates another problem. It stops the VM being self-hosting because it can’t run its own Ant task:

/home/gandalf/projects/java/classpath/jikesrvm.jamvm/build/tasks.xml:28: taskdef class org.jikesrvm.tools.ant.ForEachTask cannot be found

org.jikesrvm, you’ll note, is another disallowed prefix.


I’m still fairly disappointed with the way OpenJDK is proceeding, and I read Roman’s comments this week with interest. At least it’s not just me that feels this way. I guess it’s just that we’re impatient, but especially with the release of the code, we GNU Classpath hackers feel we want to do something to help.

Just looking at the speed with which IcedTea has developed, it’s clear that the motivation is there. However, there’s a missing link. There’s no way of feeding stuff back in to the OpenJDK project, no live source repository and an unknown bunch of Sun developers working on the same stuff. At some point, their code will appear in one of these ‘b’ source code drops and whatever we’re doing will be rendered obsolete.

Meanwhile, work on GNU Classpath has ground to a halt because there’s no motivation there any more. Why bother implementing a package when the GPLed code is out there in the OpenJDK? But there’s currently no way of joining the two together to create a Free Java implementation. I feel we’re still just as far away as we ever were, with a future much less bright at the moment. I’ve had a fantastic three years of working on GNU Classpath, and through that time the development pace has increased to an unbelievable rate and I’ve met some truly fantastic people.

I’d hate to see the results of this work go to waste. But right now is the most indecisive and scary time I’ve been through while working on the project and I just don’t know what will happen next. The current OpenJDK is in a worst state than Classpath (I’m talking about IcedTea, I don’t consider the version with binary safety pads a Free Java) and the fantastic work coming from the RedHat guys seems a little like stuff we’ve already done in Classpath.

Here’s to better times ahead.. I hope.

Finally seen some success this morning. Firstly, JikesRVM now boots. It won’t load the classes I want it to from a zip but it does boot. I found the solution following some advice from Ian Rogers last night. I copied java.lang.Runtime (the failing class) into the library interface and added a few VM.sysWriteln calls to get some debugging info. As I guessed from looking at the code, it seems the Runtime isn’t null and so an error is thrown. JikesRVM then fails to throw the error because not enough of it is there yet.

The solution is actually quite simple: I extended the test to also check that VM.fullyBooted is true. If it isn’t, it still goes ahead and initialises Runtime and this gets things going to a point where JikesRVM goes ‘oi, specify some classes!’ (well nicer than that, but you get the jist).

Unfortunately, actually specifying some doesn’t seem to work:

Boot sequence completed; finishing boot thread
java.lang.NoClassDefFoundError: Could not find the class gnu.classpath.examples.management.TestClassLoading:

Iced Success

To top it all, I just finally got a build of IcedTea through!

IcedTea is served: openjdk/control/build/linux-amd64

This is on Debian stable with a copy of gcj svn lurking around (from my earlier attempts). Biggest problem was getting it happy with a compiler; I had to use ecj 3.2 in the end from the JikesRVM build as it didn’t like my version or javac. Other funny issues include messing up the generated files because my copy of gcj has some of my debug output in it and linking against a rogue libjvm that was still floating around. It also didn’t like fastjar or any of my Sun tool wrappers, preferring the ones from Classpath.

I also had to drop back to the copy of OpenJDK I originally downloaded on the release. b15 won’t work, either built using IcedTea or from the binary drop. The binary drop of b13 does, so something went wrong since. It also fails for twisti, but he’s doing some weird build stuff with cacao so it could be that… ;)

Comments on IcedTea: seems to work well, although I wonder why it rebuilds rt.jar and jce.jar all the time, and just gets completely confused if I specify an openjdk source dir but no zip file (guess I didn’t understand that option properly)

Weather’s bad ‘ere too

This is for Andrew Cowie — it’s not only Australia seeing abnormal weather at the moment..

Sheffield Floods

Still not much further in getting JikesRVM to build on a GNU Classpath platform. It looks like I may have to give in and use Sun’s code for the time being (hopefully IcedTea, so at least it’s still Free).

Following on from last time, I got twisti to patch the hole in cacao only to fall over another large hole in the annotation support. So that’s cacao out until the student working on annotations completes the getAnnotations method.

I was assured by Andrew Haley that gcj had such support so I went and built the latest svn. And it got past that bit. Then we hit more fun, more very confusing fun.

What JikesRVM is doing at this stage is building a boot image that can then be jumped into by a small bootstrapping piece of C code. This image contains copies of the classes needed to get the VM to be self-hosting. Trouble is, in using a Classpath-based VM, there are more collisions between the new RVM classes and those in the host VM.

This bit of building the boot image involves quite a few Class.forName calls. These get confused over which classes we actually want to get, it seems (still not sure if that is meant to be the case, or whether the classloading is a bit messed up). Presumably with Sun’s VM, it only conflicts on the main API classes, and the code has special cases to deal with these.

The first problem with GCJ I found was that it can reach some odd cases where it loads a class from the RVM jar that is package-private and has a superclass which is loaded by GCJ (giving them different boot loaders, hence the compliant of a IncompatibleClassChangeError). These are anonymous inner classes that are getting named differently by GCJ. My guess is that this is because it’s using an older version of ecj (Jikes is using 3.2).

Suffice to say, JikesRVM has java.util.Collections$CheckedMap$CheckedEntrySet$1 while GCJ has java.util.Collections$6. As the former has a superclass of java.util.Collections$CheckedIterator which is loaded by the bootclassloader, an error is thrown. This isn’t the only case either; a number of inner classes in Collections are prone to this.
I’m still wondering if this is solvable by getting GCJ to build with a newer ecj. This requires adding GCCMain to a newer version. Not sure if this is even possible. I’ve got around it so far on the JikesRVM side by getting the boot image writer to ignore the error, as it does with ClassNotFound and Security exceptions (which suggests that loading the class isn’t required).

The current problem is a NullPointerException:

[echo] Exception in thread “main” java.lang.ExceptionInInitializerError
[echo] at java.lang.Class.initializeClass(libgcj.so.9)
[echo] at java.lang.Class.forName(libgcj.so.9)
[echo] at BootImageWriter.getJdkType(BootImageWriter.java:2473)
[echo] at BootImageWriter.createBootImageObjects(BootImageWriter.java:1150)
[echo] at BootImageWriter.main(BootImageWriter.java:614)
[echo] Caused by: java.lang.NullPointerException
[echo] at java.lang.VMClassLoader.getSystemClassLoaderInternal(libgcj.so.9)
[echo] at java.lang.VMClassLoader.getSystemClassLoader(libgcj.so.9)
[echo] at java.lang.ClassLoader$StaticData.(ClassLoader.java:154)
[echo] at java.lang.Class.initializeClass(libgcj.so.9)

This occurs because JikesRVM is trying to call the static initializer for ClassLoader$StaticData which in turn calls VMClassLoader.getSystemClassLoader. Note that GCJ’s copy doesn’t do this (or even contain this class); it is the Jikes class (from Classpath) that is doing this, so again it’s a case of interaction between the two class libraries.

I’m still not sure exactly where the NPE occurs (it’s somewhere in this native code). Any help would be much appreciated. The offending line is:

_Jv_CopyClassesToSystemLoader (gnu::gcj::runtime::ExtensionClassLoader::system_instance);

which calls code in natClassLoader.cc. This error occurs with a prototype build, but the same NPE occurs with a development build except this time it’s somewhere in the compilation performed by the OPT compiler.


Tried to add GCCMain (from rhug’s gcj-ecj it turns out) to ecj 3.2, and it failed:

org/eclipse/jdt/internal/compiler/batch/GCCMain.java:231: cannot find symbol
symbol : method handleWarningToken(java.lang.String,boolean,boolean)
location: class org.eclipse.jdt.internal.compiler.batch.Main
super.handleWarningToken(token, isEnabling, useEnableJavadoc);
org/eclipse/jdt/internal/compiler/batch/GCCMain.java:440: cannot find symbol
symbol : variable destinationPaths
location: class org.eclipse.jdt.internal.compiler.batch.GCCMain
this.destinationPaths = new String[this.filenames.length];
org/eclipse/jdt/internal/compiler/batch/GCCMain.java:442: cannot find symbol
symbol : variable destinationPaths
location: class org.eclipse.jdt.internal.compiler.batch.GCCMain
this.destinationPaths[i] = this.destinationPath;
org/eclipse/jdt/internal/compiler/batch/GCCMain.java:460: cannot find symbol
symbol : method disableWarnings()
location: class org.eclipse.jdt.internal.compiler.batch.GCCMain

Trying JamVM eventually proved successful. I patched the same VMSupportsCS8 hole myself (just returning FALSE), and seem to have managed to work around a bug in VMDouble.toString to do with NaN detection to get a successful build (but not a running RVM…yet…)

Yesterday, I succeeded in getting the furthest I have so far in building JikesRVM. I’m guessing I’m nearly at the end and just falling at the final hurdle, as it gets to writing the boot image:

[echo] Building bootimage. Output redirected to : /home/gandalf/projects/java/classpath/jikesrvm/target/development_x86_64-linux/BootImageWriterOutput.txt
[java] Java Result: 1
[echo] BootImageWriter: compiler arg: O2
[echo] VM_BootImageCompiler: init (opt compiler)
[echo] Exception in thread “main” java.lang.UnsatisfiedLinkError: VMSupportsCS8
[echo] at BootImageWriter.createBootImageObjects(BootImageWriter.java:1109)
[echo] at BootImageWriter.main(BootImageWriter.java:614)

What’s proved such a problem is not so much JikesRVM itself as ant. It seems to assume a Sun-esque JDK and tries to run everything from tools.jar by default (presumably for efficiency, as this avoids spawning another VM). I’ve got round this by creating a tools.jar using OpenJDK and a little build system I hacked together. I’ve just announced this on the OpenJDK distro packaging mailing list, and hope that it can be made public in the same place as IcedTea (which can now build a Free OpenJDK).

Because this little bit of hackery gives me a tools.jar containing javac and javah, and an apt binary, the JikesRVM build process is satisfied. Of course, javac and javah have always been around on my path; it just doesn’t seem to want to use them. Next step is to see if the GNU Classpath tools will work as well, with the addition of a little wrapper for javah (so com.sun.tools.javah.Main exists, simply calling the GNU equivalent).

Any help on this final build problem would be much appreciated too. I’m eager to get hacking and actually contributing code for SoC!


I’ve narrowed down the problem above which is nothing to do with Jikes RVM, but instead is due to a hole in CACAO’s implementation of the java.util.concurrent framework. VMSupportsCS8 is a native method which returns true if the underlying JVM supports lockless CompareAndSet for longs. I’m now looking around for VMs that do provide this…

Next Page »