the plan for the JIT

[Allison Randal]

This is plan A, and subject to revision as we go along.

Andrew put together some great notes on the subject, worth a read: 
https://trac.parrot.org/parrot/wiki/JITRewrite

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.

Allison