+The LuaJIT 1.x series represents +the current stable branch. +Only a single bug has been discovered in the last two years. So, if +you need a rock-solid VM, you are encouraged to fetch the latest +release of LuaJIT 1.x from the » Download +page. +
++LuaJIT 2.0 is the currently active +development branch. +It has Beta Test status and is still undergoing +substantial changes. +It has » much better performance than LuaJIT 1.x. +It's maturing quickly, so you should definitely +start to evaluate it for new projects right now. +
+ +Current Status
++This is a list of the things you should know about the LuaJIT 2.0 beta test: +
+-
+
-
+Obviously there will be some bugs in a VM which has been
+rewritten from the ground up. Please report your findings together with
+the circumstances needed to reproduce the bug. If possible, reduce the
+problem down to a simple test case.
+There is no formal bug tracker at the moment. The best place for +discussion is the +» Lua mailing list. Of course +you may also send your bug reports directly to me, +especially when they contain lengthy debug output or if you require +confidentiality. +
+ -
+The x86 JIT compiler only generates code for CPUs with support for
+SSE2 instructions. I.e. you need at least a P4, Core 2/i3/i5/i7,
+Atom or K8/K10 to get the full benefit.
+If you run LuaJIT on older CPUs without SSE2 support, the JIT compiler +is disabled and the VM falls back to the LuaJIT interpreter. This is faster +than the Lua interpreter, but not nearly as fast as the JIT compiler of course. +Run the command line executable without arguments to show the current status +(JIT: ON or JIT: OFF). +
+ -
+The VM is complete in the sense that it should run all Lua code
+just fine. It's considered a serious bug if the VM crashes or produces
+unexpected results — please report this. There are only very few
+known incompatibilities with standard Lua:
+
-
+
- +The Lua debug API is missing a couple of features (return +hooks for non-Lua functions) and shows slightly different behavior +(no per-coroutine hooks, no tail call counting). + +
-
+Some of the configuration options of Lua 5.1 are not supported:
+
-
+
- The number type cannot be changed (it's always a double). +
- The stand-alone executable cannot be linked with readline +to enable line editing. It's planned to add support for loading it +on-demand. +
+ - +Most other issues you're likely to find (e.g. with the existing test +suites) are differences in the implementation-defined behavior. +These either have a good reason (like early tail call resolving which +may cause differences in error reporting), are arbitrary design choices +or are due to quirks in the VM. The latter cases may get fixed if a +demonstrable need is shown. + +
+ -
+The JIT compiler falls back to the
+interpreter in some cases. All of this works transparently, so unless
+you use -jv, you'll probably never notice (the interpreter is
+» quite fast, too). Here are the known issues:
+
-
+
- +Most known issues cause a NYI (not yet implemented) trace abort +message. E.g. for calls to some internal library +functions. Reporting these is only mildly useful, except if you have good +example code that shows the problem. Obviously, reports accompanied with +a patch to fix the issue are more than welcome. But please check back +with me, before writing major improvements, to avoid duplication of +effort. + +
- +Some checks are missing in the JIT-compiled code for obscure situations +with open upvalues aliasing one of the SSA slots later on (or +vice versa). Bonus points, if you can find a real world test case for +this. + +
- +Currently some out-of-memory errors from on-trace code are not +handled correctly. The error may fall through an on-trace +pcall (x86) or it may be passed on to the function set with +lua_atpanic (x64). + +
+
Roadmap
++Please refer to the +» LuaJIT +Roadmap 2011 for the latest release plan. Here's the general +project plan for LuaJIT 2.0: +
+-
+
- +The main goal right now is to stabilize LuaJIT 2.0 and get it out of +beta test. Correctness has priority over completeness. This +implies the first stable release will certainly NOT compile every +library function call and will fall back to the interpreter from time +to time. This is perfectly ok, since it still executes all Lua code, +just not at the highest possible speed. + +
- +The next step is to get it to compile more library functions and handle +more cases where the compiler currently bails out. This doesn't mean it +will compile every corner case. It's much more important that it +performs well in a majority of use cases. Every compiler has to make +these trade-offs — completeness just cannot be the +overriding goal for a low-footprint, low-overhead JIT compiler. + +
- +More optimizations will be added in parallel to the last step on +an as-needed basis. Sinking of stores +to aggregates and sinking of allocations are high on the list. +More complex optimizations with less pay-off, such as value-range-propagation +(VRP) will have to wait. + +
-
+LuaJIT 2.0 has been designed with portability in mind.
+Nonetheless, it compiles to native code and needs to be adapted to each
+architecture. The two major work items are porting the the fast interpreter,
+which is written in assembler, and porting the compiler backend.
+Most other portability issues like endianess or 32 vs. 64 bit CPUs
+have already been taken care of.
+Several ports are already available, thanks to the +» LuaJIT sponsorship program. +More ports will follow in the future — companies which are +interested in sponsoring a port to a particular architecture, please +use the given contact address. +
+ - +Documentation about the internals of LuaJIT is still sorely +missing. Although the source code is included and is IMHO well +commented, many basic design decisions are in need of an explanation. +The rather un-traditional compiler architecture and the many highly +optimized data structures are a barrier for outside participation in +the development. Alas, as I've repeatedly stated, I'm better at +writing code than papers and I'm not in need of any academic merits. +Someday I will find the time for it. :-) + +
- +Producing good code for unbiased branches is a key problem for trace +compilers. This is the main cause for "trace explosion". +Hyperblock scheduling promises to solve this nicely at the +price of a major redesign of the compiler. This would also pave the +way for emitting predicated instructions, which is a prerequisite +for efficient vectorization. + +
+