June 2006

It’s been a little while since I last blogged, and things have moved on quite a bit with the SoC project. Last week, I finally got a copy of the huge GCC tree (all several gigabytes of it), and played about with GCJ. I now have an implementation of the runtime bean for it.

Unfortunately, it’s not going anywhere fast, as I still don’t have a copyright assignment for GCC. For some reason, the FSF folks now want a disclaimer from the University, which seems to be nigh on impossible to obtain (no-one I’ve spoken to knows anything about the legal stuff at the Uni) and unnecessary (I’m not working on this for my research, which is what the Uni policy covers).

That aside, I’ve broken our original proposed strategy to avoid this problem, and started writing some more beans. This week, I added the class loading and thread bean interfaces to HEAD, along with an implementation and new VM interface for the class loading bean. The thread bean is proving to be quite an undertaking. For one thing, we were missing some 1.5 threading methods which are needed by the bean. It seems to want lots of information about the thread, including monitoring when it changes state, how many times it goes in to the blocked, waiting and timed_waiting states, and, if contention monitoring is supported, how long it spent in these states. Phew! The changes were so big I haven’t written the bean yet; I thought just the interface and the ThreadInfo class would be enough in one patch. Hopefully, the others will be less disruptive to the VMs.

I started this week by adding an implementation of the runtime bean, which allows the user to probe for all the sorts of information about the virtual machine. Well, I say all sorts, but most of what’s available from the beans is little more than a gathering together of stuff that is already accessible (lots of the runtime bean stuff just points to named properties). The garbage collectors and memory managers look a bit more interesting (for one thing, you can then see multiple collectors or managers), but the designers of these seem obsessed with counting the time it takes to do things. With the runtime bean, will we now see people boasting about their virtual machine uptime in the same way they do about their physical machine?

With some great feedback from the folks hanging about on IRC (including Michael Koch, Christian Thalinger and Tom Tromey), we sketched out a rough idea of the required native hooks and a good choice of properties for obtaining the boot class path (which e.g. CACAO and gcj already supply a sun.boot.class.path). The native hooks for the runtime bean only number two (one for arguments and one for start time), but no doubt the others will bring more.

I’m now working on trying to turn the two existing beans into dynamic beans, before starting to hack on an implementation of these native methods in gcj. Making them dynamic beans will enable the attributes to be obtained dynamically from the bean and will also provide the translation support required in the management factory documentation. However, this seems to require a lot of classes in javax.management (and we only had one to start with, Attribute, which Audrius Meskauskas put together). These classes are clearly designed for being accessed from languages over than Java, as they define a lot of classes simply to wrap stuff that already exists. For instance, the attribute list is just an array list; fine in Java but other languages don’t have such predefined collections. It also has its own exception hierarchy, which results in me having added nine classes to javax.management so far, and still not even having the dynamic mbean interface; these are merely its dependencies! But still it means our percentage is looking more respectable…

We got some good news the other night — RMS approved using ecj as a driver for gcj. Once this goes ahead, we’ll have two compilers supporting building a Classpath with all the 1.5 language goodies, which means we’ll probably be able to merge the generics branch back to HEAD and have just one Classpath again…

Unfortunately, we will drop from three to two compilers in the process; it doesn’t look like Jikes will ever be updated to match 1.5. It’s pretty sad that basically only one Free compiler will support 1.5 (ecj, and ecj masquerading as gcj for the front-end part). Tom Tromey’s experiment with a new frontend, gcjx, is, to use his own words, ‘dead’. I guess the amount of extra stuff that got added in is just too much.

So, how soon will we now have a final merge of the two branches? We’re basically still waiting on gcj, although with the politics now sorted out, things look a lot more hopeful. If some basic support could be snuck in for 4.2, we could have support pretty soon (by the end of the year). If things keep going the way they are, we might just have 1.5 largely done by the time it gets to October and 1.6 appears.

In prospect of this merge, I’ve been trying to ease things a little this weekend, by getting most of the stuff that can go over on to HEAD. Unfortunately, it does mean there are a few files with some nasty hacks in and missing methods that will never be resolved until the merge occurs. The classes are still functional; I’m limiting it to stuff where a few minor removals or changes will get something workable on to the main branch, and where the changes that are made will show up in our JAPI results. Things will be much nicer though, when everything is one again.

So, I committed the first chunk of code for java.lang.management earlier this week. This consisted of basically the easy bits: the operating system bean and the factory method to get an implementation of it. This implementation basically just returns the appropriate properties (e.g. os.name, os.version), and the methods are simply the equivalents of System.getProperty(“os.name”) or whatever. Implementing this, however, does give the package 7.55% in JAPI which is a nice start and makes Classpath look a bit better.

The interesting stuff comes next. I’m probably going to tackle the runtime bean next, which is partly wrapper stuff again, but also partly more interesting stuff. Some of it will require some gcj/gij hacking I think, so I’ve started looking at the code base for that. Any pointers would be welcome.

On flicking through the docs, I noticed that we’ll need some bits from the javax.management stuff (basically the OpenBean types), but these look fairly easy to implement. There’s also a enum lurking around which I didn’t spot before. Luckily, it doesn’t seem to cause much of problem (basically a few methods I guess, in one of the beans) and it can be done on the generics branch.

Speaking of which, that also now has a copy of the management interfaces, as I followed this little bout of hacking with a quick merge. I’m trying to keep these on a weekly basis at the moment, because the whole process is a lot smoother when the code drop is smaller. Most of the problems this time were caused by myself anyway, as I merged the enum serialization stuff back to HEAD, which then tried to come back to the branch in the merge…. I keep trying to move more stuff back to HEAD. The main issue at the moment is that it needs documenting first on the branch (I don’t want to move undocumented code on to HEAD). Someday (basically when gcj gets ecj and generics support I guess), the whole thing will get merged back together, but hopefully I’ll be able to minimise this in the meantime to just the required differences.