I’m in Toronto this week, visiting the office and talking with co-workers. It is as great here as always; I love the occasional visit to a big city, riding the subway, etc — doing the kinds of things you can’t do in Boulder. Seeing folks face-to-face occasionally is also very helpful for my morale; brainstorming and discussing what we’re doing is energizing.
Someone posted a link to the bumptop video on Mugshot today. I’m always entranced by these gee-whiz desktop ideas. This one is no different, I loved watching the video and then I made Andrew Overholt watch it too. Unfortunately he pointed out that if you watch it you may notice what you don’t see: any actual use of an application. And, it is pretty hard to see how this would improve my productivity at all. For one thing I barely even use Nautilus, so improvements to abstract document manipulation are not likely to do much for me.

I also read The Six Dumbest Ideas in Computer Security recently. This is interesting and easy to read. I often think that the most important frontier in programming is reliability, which is similar to his points about designing in security. Unfortunately this area isn’t sexy enough, so language and platform designers tend to focus on productivity and ease of hacking, rather than ease of getting things right. Java, IMO, started off with a nice reliability boost over C, but these days it is also headed down a bad road, what with AOP (which I really dislike) and the forthcoming XML-in-the-language thing.

I’ve been looking at moving my blog to something less lame —
right now I can’t blog while I’m traveling, which is why I still
haven’t written about my trip to the Red Hat Summit. I’ve also been
looking at other software for creating web sites.

While exploring I ran across the Open Source CMS site.
This site lets you play with many different CMS, blog, photo gallery,
etc, installations, so you can try them out before committing to one.

So far my experiences with these programs haven’t been very
positive. I’ll write more about that later.

I’ve been working steadily on replacing gcj’s front end with the
Java compiler from Eclipse. This is largely working now. I have a
new main program for the Eclipse compiler, and I have gcc set up to
invoke this (via the magic of gcc specs — an evil little ad hoc
scripting language that you should hope you never have to learn).

The new driver is a little funny. When ecj compiles a file, it
writes the classes to a jar which gcj compiles. This way we don’t
have to have an arbitrary number of temporary files for communication,
e.g. for all the inner classes. This takes advantage of java’s
built-in ability to make jars, and gcj’s existing ability to compile a
jar file all at one. I thought this was amusing, anyway… maybe I’ve
been working too much.

I thought this would be very simple, but I should have realized
that this would reveal every bizarre class file compilation bug in
gcj, some of which can only be seen if you are compiling the core
class library this way. For example, the bytecode verifier needed a
special case to handle the constructor in Object.

In any case, I can now build all of libgcj this way. I’m
debugging a few runtime failures now.

LLVM-based JIT

Aside from the whole exception handling mess — which experts more
expert than I are, hopefully, busily hacking on — the JIT seems to be
working reasonably well. I’m just about ready to clean up the API and
check it in (as an experimental preview), I don’t think any more
changes in that area will be needed in the near future.

There are still a few lurking code generation bugs. Nothing too
hard, just mishandling jsr a little.

I recently added the first bits of recompilation to the JIT. Now
it will realize when it resolves a constant pool entry, and mark the
method as ready for re-jitting. The idea here is that before linking,
a constant pool reference requires a method call to incrementally link
the class, whereas after linking, a constant pool reference is simply
a constant. Another similar optimization is that when we initialize a
class, we mark the method as ready for re-jitting — the code to lower
from bytecode to LLVM will check a class’ state and avoid emitting
initialization calls as needed.

This still hasn’t seen much testing. And, to really do a good job
here we have to add profiling code of some kind. I really need to
read the literature here. If only there were time.