the plan for the JIT
allison at parrot.org
Wed Sep 9 19:30:28 UTC 2009
This is plan A, and subject to revision as we go along.
Andrew put together some great notes on the subject, worth a read:
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
More information about the parrot-dev