February 2008 – gbenson.net

Talking to people at FOSDEM made me realise just how much LiveJournal annoys me. When I started this blog I didn’t want to host it myself — the last time I tried that I spent more time fiddling with it than writing it! — but apparently I miss being in control, and since my ISP provides free WordPress installation maintainence… well… welcome to my new domain!

While I was moving the entries across I realised it’s been ages since I did a proper post. I first committed zero exactly a month ago, and if you’d asked me then what I’d like to have achieved now I’d have said an s390x port — at least! Stuff kept getting in the way, however. Fixing it up for amd64 made me realise that the core build patch was incomplete at best, and that the ports patch was far more complicated than it needed to be as a result. I spent a couple of weeks separating and rearranging the two — the tree is in a great state for new ports now — but then all kinds of things kicked off. OpenJDK 6 got released, IcedTea 7 started failing in koji, there was preparing for FOSDEM, and FOSDEM itself, and some other stuff that Lillian and I are doing… and still there are no new ports!

Anyway, hopefully the IcedTea 7 failure is #435337 — aka not my problem — but the OpenJDK 6 stuff is going to keep me busy for a time. The delay may turn out to be a good thing, however: chatting with aph made me realise I can probably make it such that new ports require no new patching at all if I generate some bits and pieces from the configure script. I’m letting that one cook in my head while I do the OpenJDK 6 stuff.

For anyone who wants them, my FOSDEM slides are here.

When I’m testing my stuff I don’t use vanilla IcedTea. The standard debug build is an icedtea-against-icedtea which takes hours and hours to complete. Instead, I have a set of patches which enable assertions and disable optimization int the icedtea-against-ecj build. This builds much faster. If you are working on zero (or something else Hotspot) then you may find them handy:

cd /path/to/icedtea
wget http://inauspicious.org/files/icedtea/mixtec-patches.patch
patch -p1 < mixtec-patches.patch
make clean
make icedtea-against-ecj

Once you have that, you can use make hotspot to rebuild the JVM only, without going all the way into and out of the class library makefiles.

Note to self: “error while loading shared libraries: libjvm.so: R_PPC_REL24 relocation at 0x0fe4cc80 for symbol ‘memcpy’ out of range” means that something in libjvm.so was not built with -fPIC. If you statically linked some library in there, it’s probably that.

Now that the zero-assembler port is committed I’ve been thinking about dropping the ppc-specific one. The plan is to use zero for our other platforms (s390, s390x, ia64 and arm) and there’s no obvious reason to maintain a separate port for ppc and ppc64. This past two days aph and I ported zero to amd64 and I’ve been thinking of ways to integrate zero into the build system so that you can choose to use it on any platform with minimal effort. This will be easier and clearer without a load of ppc-specific stuff knocking around in there. There are a couple of bugs in the ppc-specific port too, bugs I noticed while writing zero, and I just can’t be bothered to fix them.

I did some simple speed tests, the time in seconds taken by jar cf tools.jar:

	ppc	zero
32-bit	67.6	70.3
64-bit	67.9	69.7

Not bad. A look at the call graph shows most of the method calls are interpreted methods, so I’m not sure it’s entirely representative — I’d expect programs doing a lot of native calls to be hit harder — but I like it. I’m interested to know why 64-bit zero is faster than 32 too — that’s not what you’d expect on ppc — but that can wait until I get round to some profiling. I want to get it running on the other platforms first.