Today I wrote another optimization pass for gcj. This one
collapses equivalent vtable references and array length references.
You’d think that GCC itself would do this, but there’s no way to tell
the optimizers that a given field is write-once.

Really I should fix GCC to do this… but writing a new pass is
easy to do, and fixing the generic code looks daunting.

The other day I also rewrote my devirtualization pass to use the
SSA propagation engine. Again, simple to do, and it improved the
results a bit.

Hacking GCC these days, while still tricky in some details, is
just enormously simpler than it was 5 years ago. Kudos to all the
tree-ssa folks who made this happen.

ecj

I spent some time this week hooking ecj up to gcj, as threatened.
I’ve got a new driver for the eclipse compiler that eases the argument
processing a bit. This is working well enough now that I was able to
successfully compile some source code using generics by running the
gcj driver.

If only I had a decent place to check this in. I wonder if the SC
would let me make a branch for this, even though it is in political
limbo.

JIT etc.

I started writing my GCC optimizer passes because I was curious
about writing a devirtualization pass for LLVM. I wrote about half of
it and then thought that surely this would be just as simple for
tree-ssa.

I’ve been thinking a bit about heuristics for when the libgcj JIT
should recompile. The easy ones are things like: recompile when
classes are initialized, so we can remove initialization calls from
inside loops; and recompile when constant pool references are
resolved, so we can replace expensive indirect accesses with cheap
direct ones.

There’s probably a lot of literature out there that I should be
reading on other times this is worthwhile — detecting when partial
specialization is worthwhile, profile-directed runtime optimization,
etc. Maybe HLVM will help.

Actually doing the recompilation is simple; LLVM provides the
needed hooks. For things like constant pool references, I think I
will take the simple approach of simply re-lowering from bytecode to
LLVM. If this proves to be too expensive, it can always be changed, I
think. But I suspect it won’t be. And, anyway, it will be fun
finding out.