The JIT Plan

A big thing has happened today with JIT: Allison has taken a look at all the information and laid out a plan for replacing Parrot's ailing JIT system. Since she said it better then I ever have, I'll just post her email here for your viewing enjoyment:

The current JIT will be disabled, with Parrot set to run the default 'fast' core when the 'jit' core is selected. This change can occur immediately following the 1.6 release. Between 1.6 and 1.7, code supporting the current JIT can be removed. A deprecation notice will go in before 2.0, eliminating the 'jit' runcore option. (There will be other ways of enabling and disabling JIT functionality later, but it won't be a runcore. For one thing, enabling the JIT is likely to require special compilation, see later comments.)

The basic requirement for the replacement JIT is the ability to generate machine code on the fly at runtime for a code object (Sub, Method, NCI, etc), so that any subsequent executions of that code object run the machine code directly. It must support all of Parrot's target platforms.

LLVM provides a set of tools that look promising for allowing us to quickly develop a JIT, taking advantage of the platforms they already support. (Note that LLVM currently has limited support for Windows, so it's not quite there on *all* our target platforms.) The plan is to develop a rapid prototype of an LLVM-based JIT, to see if it might work as the primary Parrot JIT, or perhaps as one of several JIT strategies.

The prototype will implement a subset of the core Parrot ops in a lightweight language ("Lorito", an extension of what we've already been talking about for that language). For the sake of the prototype, the Lorito compiler will output LLVM's Low-level Intermediate Representation (LIR), but the language will be developed so that it's general enough that it could be compiled to various different output formats (including C).

The old JIT compiled each op down to a separate chunk of machine code. The new JIT would potentially be able to JIT at the level of a single opcode (since the definitions are there), but the greater speed gains will come from JITing entire subs (where the opcode definitions are building blocks for larger units to compile, rather than compiled individually), so that's where the prototype will focus.

The JIT is not a runcore (it's a dynamic compilation strategy), but it also doesn't necessarily have to be compatible with every runcore variant we've developed.

Using LLVM for the JIT (or any external JIT library) will add an optional dependency. A Parrot built without LLVM will simply disable the JIT features.

I'll post more indepth information about all this in the days ahead. Also, make sure to keep up with the planning page on the wiki, where things are starting to come together.