One of my wish-list items for libgcj hacking is to port the whole
mess to LLVM. LLVM is a low
level virtual machine; I think of it as a rough equivalent of the GCC
middle and back ends, only written in C++ and with a more flexible
design. For instance, LLVM can be used as a JIT as well as
ahead-of-time, and it can also do things like whole program
optimizations.

Hooking gcj and libgcj to LLVM doesn’t look particularly hard,
though it would require a larger block of free time than I seem to be
able to dig up. And, LLVM may not be quite ready for the
adventure… its exception handling is different (which is ok in a
closed world, but may matter more if you want real interoperability
with gcc-compiled C++ code), plus LLVM has notably fewer back ends,
and is missing some that matter. These are just minor bumps
though.

Today I read an interesting powerpoint
presentation about the future of language design. It is full of
nice observations, for instance the idea that the implementation of
the next big programming language will probably be slower than what
we’re using now — since what we’re using now will have been heavily
optimized over the years.

This is where LLVM comes in. I think, these days, aspiring
language designers don’t really need to skimp on performance in order
to get their tools up and running. In the old days you would write an
interpreter or generate C code; but with LLVM it looks just as easy to
simply write a JIT. (It is also surprisingly easy to write a GCC
front end these days, so that is another viable approach to
implementing your language.)

The point of all of this is that free software lowers
institutional barriers, making division of labor more possible. In
other words, you write your language front end, and somebody else does
most of the worrying about turning it into efficient code.