First Steps on JIT Overhaul

Allison's email was the start of something big, and I have been absolutely excited by the prospect of a proper JIT system since she sent it. It's going to be a lot of work and will have a dramatic and overarching impact on our entire codebase, but it will be well worth it. There are a few things I especially like about this plan: There are a lot of options so we can test what does and does not work as we go. We can break it up into stages so huge changes aren't happening in disruptive chunks. We can get started immediately. We can parallelize several tasks so many people can be working towards the ultimate goal in many ways.

Mostly what I am excited about is that the rest of the developer team has been so excited about it as well. bacek has started moving through the ticket queue closing tickets relating to our current JIT system that won't ever be fixed now. moritz has been talking to developers on #llvm. People have started adding info to the wiki and adding their names to the list of tasks, and giving lots of good feedback as they go!

In the short term, possibly immediately following the 1.6.0 release, the parrot command line interface is going to be tweaked a little bit to hide the current JIT system. The command line argument --runcore=jit is going to be redirected so that it invokes the fastcore instead of the JIT core. What this does is removes the unworking underlying system but keeps the user interface the same. In the end, --runcore=JIT will not only continue working for users that already have it but will actually start working on platforms that have never had it. We're lying because it's not really executing a JIT engine underneith, but the deprecation policy doesn't say anywhere that we can't lie a little bit.

With the commandline papered over, we can get started on the work of removing the guts of the JIT system. This is going to be both interesting and fun work, because we're going to be deleting lots of evil code, but we're also going to need to preserve some functions for the NCI thunk generation. I think [hope] that once we start cleaning things out that we will be able to radically simplify and improve the NCI thunk generator.

LLVM seems like a really cool JIT solution for us to use, and it actually offers a lot more functionality then we will need (or even want). One big benefit is that LLVM operates on a low-level platform-independent intermediate representation (IR), which should be easy to translate to from Parrot ops. Some of our ops, especially the arithmetic ones, will have a very direct translation indeed. We're probably going to want to abstract away the details and create macros or even an improved syntax parser to take away the rough edges so we aren't programming in assembly, but that's something we can worry about later.

We're going to need the configuration system to detect LLVM. Nothing more to say about this one, we've got a great configuration system and this should be no issue.

These other steps out of the way, we are going to need to modify parrot to build the subroutines from LLVM IR fragments, then use LLVM to compile those subs into machine code at runtime and execute them. This step is the biggest one where everything comes together, but luckily we don't need to worry about all the details just yet.