I have mixed feelings about this portable interpreter work at the moment. On the one hand it’s going great: every day feels like I’m progressing faster and faster, partly because I’ve written tools to do the awkward bits and partly because now when I get build errors I have a much better idea of where to fix them. But on the other hand it’s a little daunting, because it’s becoming clear that some big things have changed since it was last used and the lack of revision history means I can’t just go back and see how they were changed in the JITs. So I don’t know what to think.

One cool thing is that before I started trying to build the portable interpreter I toyed with the idea of implementing the JVM interface in a free VM and using it as a replacement for libjvm.so — and it turns out twisti is doing just that! So my “maybe this would work” fallback has turned into a “this will work” without me lifting a finger!

This past few days I’ve been wrestling with a minor flaw in my porting plan, namely that some files are reference not methods but constants, and I have no idea what values to assign to them. I’ve been picking random values to get the build to progress, but that’s just storing up hard to debug errors for when I finally get to run the thing. But I finally figured out how to do this properly:

  • Every time make complains about a missing file, touch it.
  • Every time something complains about a missing method, stub it with something that throws an error.
  • Every time something complains about a missing constant, create one randomly but mark it with XXX EVIL.

Then:

  • Remove all evil constants, and stub everything that needed them with the same error-throwing thing as before.
  • Every time a stub gets hit, write the real method.

I’m glad I figured this one out, it’s been bugging me.

Yesterday I made a templater to generate machine-specific files for OpenJDK. I’m not 100% convinced that all the files make says are missing are necessary — the portable interpreter is old code, and it’s possible there are files listed as dependencies that are only required for JITs — and I don’t intend writing assembler that isn’t used so the way I plan to proceed is:

  • Every time make complains about a missing file, touch it.
  • Every time something complains about a missing method or whatever, stub it.
  • Every time a stub gets hit, write the real method.

The great thing about this is that the first two steps can be done in the templater. Nominally I’m only supposed to be getting it running on ppc, but there’s four other platforms that we care about and others that other distributions want. The idea is that the longer I can keep my work generic the easier individual ports will be.

Today I hacked the OpenJDK build system so that it recognises when it’s running on a platform without a JIT and enables the portable interpreter. Now it’s at the point where the build fails because the platform dependent flags files globals_$cpu.hpp and globals_linux_$cpu.hpp don’t exist so I’ve been dredging through the existing ones to see what my new ones need. There’s some stuff in there which I’m tempted to rationalize but I’m going to leave it alone in the interests of keeping my patch simple. I figure keeping tangential stuff out is the path to easy patch acceptance when the time comes.

Now I’m back at work I can get down to some OpenJDK stuff in earnest. I grabbed myself the task of getting it up and running on the architectures that we support but Sun don’t.

The deal is that each processor that Sun supports has a JIT, and at the core of each JIT is an architecture description file, 10,000 lines or so of psuedo-assembler. Even one platform wouldn’t be an option for me, and I have five. But it turns out that Sun did an ia64 port way back when, and because ia64 assembler is wacky they wrote an interpreter in C++ instead. They dropped ia64 for Java 5, but the interpreter is still in the codebase and it looks like the build scripts can build it. Sort of. I mean, I guess it’s not been touched since 2004, but I live in hope.

Anyway, dwmw2 lent me a big old ppc64 box, so I’m trying to bootstrap OpenJDK on it. I’ll post some patches soon, probably Monday…