Summer of Code


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…

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.

So, it seems my Summer of Code proposal to work on java.lang.management has been approved. I have to say I was quite surprised. Given how successful it was last year, and the amount of additional organisations available this year, I didn’t think I stood that much of a chance. But, here we are…

The initial confusion over who got in didn’t help either. I didn’t wait up on the Tuesday for the results (the Google times being in PST means that it’s some eight hours later here in the UK), and so I was greeted with all the controversy on Wednesday morning. I checked my section on http://code.google.com/soc and found that the application had been accepted, but I wasn’t sure if this meant the GCC guys or Google had. Checking my mail didn’t bring any joy, until I later realised that the mail would, of course, have gone to my gmail account rather than my more usual one. There I did find an accepted e-mail, and this was further backed up by a quick chat with Mark Wielaard (who will also be my mentor, it turns out).

I guess I now need to think about making a start on things. Already being a GNU Classpath contributor makes things a little odd as I’ve already posted quite a few patches over the last few years. The SoC project will mean concentrating on one particular thing on my own, which is something new, and also involves a fair bit of playing around with gcj, which I haven’t yet had chance to do… so things should still be pretty interesting. But now doubt I still find myself committing the odd bit of other stuff as well, if just the merges between HEAD and generics.

I’ll probably start by tackling some of the easier bits, especially as I can’t do any low-level stuff until all the stuff goes through for GCC access. The package is basically made up of several disparate beans, each of which I feel can be worked on in isolation. The obvious initial target is to do the OS one, as this doesn’t require any native code (it just wraps up a few calls that already exist inside a bean). By the time I get on to the second bean and need to do some native stuff, hopefully I should be sorted for GCC…. which reminds me I also need to find some hard disc space for this at some point.

Should be fun… :)

« Previous Page