It’s been a while. I’ve been doing loads of little things lately, and that tends to stop me blogging. If I’m working on only one big thing then I tend to write about it as a break, often at the end of the day when I don’t want to start anything else, but hopping from task to task means there’s not one obvious thing to either a) write about or b) take breaks from. Ah well…
Probably the single biggest thing is that I started the process of getting an official OpenJDK porters project for zero. Zero’s been pretty much stable since the end of March so it’s high time I did this, but I’ve been procrastinating about it because I’m not sure how I’ll be able to develop in that environment. I want my local tree to be as close as possible to whatever upstream I’m using, which is currently the ecj-bootstrap side of IcedTea, but I won’t be able to use ecj to build straight from a project repository without either applying and committing the icedtea-ecj.patch (bad) or applying it locally and having a non-buildable repository (also bad). I may have to bite the bullet and use IcedTea to build it, which isn’t as bad as it initially seems since the target I use for rebuilds contains no Java. The initial build will be painful but I’ll just have to do it and be more careful not to blow away my tree!
Of course, the increasing interest in zero means I’m getting more bug reports. A few people have mentioned builds failing with java.lang.IllegalArgumentException: disparate values. I assumed they were all the same, so I investigated (and fixed) it on ia64, but that particular issue was little-endian specific and so doesn’t explain that people have been seeing it on ppc EPEL. It seems that this is the first place in the build where floating point values are used and checked, so this message is not one specific error but a catch-all for generic floating point bugs. Anyway, if you’re seeing this error then please let me know.
I’ve been thinking about TCK runs too. I didn’t fancy the idea of setting up an entire TCK environment on ppc, so I filed it in my head under “Future work”, but it occurred to me that zero works (or should do) on amd64 too, so it shouldn’t be too difficult to drop it into our nightly tester. I’ve not done more than thinking about this as yet since there’s not much point in doing it without copious free time to fix the thousands of bugs it’ll doubtless find — which I don’t have!
All this zero stuff has left Shark on the back-burner for a bit, but work there is progressing too. Lately I’ve been working on making unimplemented stuff abort only that compilation (not the entire VM) so that a) people can use it in it’s unfinished state, and b) I can run some benchmarks and get some idea of the progress I’m making.
