summaryrefslogtreecommitdiff
path: root/doc/status.html
diff options
context:
space:
mode:
authorMike Pall <mike>2009-12-08 19:46:35 +0100
committerMike Pall <mike>2009-12-08 19:46:35 +0100
commit55b16959717084884fd4a0cbae6d19e3786c20c7 (patch)
treec8a07a43c13679751ed25a9d06796e9e7b2134a6 /doc/status.html
downloadluajit-2.0.0-beta1.tar.gz
luajit-2.0.0-beta1.tar.bz2
luajit-2.0.0-beta1.zip
RELEASE LuaJIT-2.0.0-beta1v2.0.0-beta1
Diffstat (limited to 'doc/status.html')
-rw-r--r--doc/status.html235
1 files changed, 235 insertions, 0 deletions
diff --git a/doc/status.html b/doc/status.html
new file mode 100644
index 00000000..23c14c76
--- /dev/null
+++ b/doc/status.html
@@ -0,0 +1,235 @@
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
2<html>
3<head>
4<title>Status &amp; Roadmap</title>
5<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
6<meta name="Author" content="Mike Pall">
7<meta name="Copyright" content="Copyright (C) 2005-2009, Mike Pall">
8<meta name="Language" content="en">
9<link rel="stylesheet" type="text/css" href="bluequad.css" media="screen">
10<link rel="stylesheet" type="text/css" href="bluequad-print.css" media="print">
11<style type="text/css">
12ul li { padding-bottom: 0.3em; }
13</style>
14</head>
15<body>
16<div id="site">
17<a href="http://luajit.org"><span>Lua<span id="logo">JIT</span></span></a>
18</div>
19<div id="head">
20<h1>Status &amp; Roadmap</h1>
21</div>
22<div id="nav">
23<ul><li>
24<a href="luajit.html">LuaJIT</a>
25<ul><li>
26<a href="install.html">Installation</a>
27</li><li>
28<a href="running.html">Running</a>
29</li><li>
30<a href="api.html">API Extensions</a>
31</li></ul>
32</li><li>
33<a class="current" href="status.html">Status</a>
34<ul><li>
35<a href="changes.html">Changes</a>
36</li></ul>
37</li><li>
38<a href="faq.html">FAQ</a>
39</li><li>
40<a href="http://luajit.org/download.html">Download <span class="ext">&raquo;</span></a>
41</li></ul>
42</div>
43<div id="main">
44<p>
45The <span style="color: #0000c0;">LuaJIT 1.x</span> series represents
46the current <span style="color: #0000c0;">stable branch</span>. As of
47this writing there have been no open bugs since about a year. So, if
48you need a rock-solid VM, you are encouraged to fetch the latest
49release of LuaJIT 1.x from the <a href="http://luajit.org/download.html"><span class="ext">&raquo;</span>&nbsp;Download</a>
50page.
51</p>
52<p>
53<span style="color: #c00000;">LuaJIT 2.0</span> is the currently active
54<span style="color: #c00000;">development branch</span>.
55It has <b>Beta Test</b> status and is still undergoing
56substantial changes. It's expected to quickly mature within the next
57months. You should definitely start to evaluate it for new projects
58right now. But deploying it in production environments is not yet
59recommended.
60</p>
61
62<h2>Current Status</h2>
63<p>
64This is a list of the things you should know about the LuaJIT 2.0 beta test:
65</p>
66<ul>
67<li>
68The JIT compiler can only generate code for CPUs with <b>SSE2</b> at the
69moment. I.e. you need at least a P4, Core 2/i5/i7 or K8/K10 to use it. I
70plan to fix this during the beta phase and add support for emitting x87
71instructions to the backend.
72</li>
73<li>
74Obviously there will be many <b>bugs</b> in a VM which has been
75rewritten from the ground up. Please report your findings together with
76the circumstances needed to reproduce the bug. If possible reduce the
77problem down to a simple test cases.<br>
78There is no formal bug tracker at the moment. The best place for
79discussion is the
80<a href="http://www.lua.org/lua-l.html"><span class="ext">&raquo;</span>&nbsp;Lua mailing list</a>. Of course
81you may also send your bug report directly to me, especially when they
82contains lengthy debug output. Please check the
83<a href="contact.html">Contact</a> page for details.
84</li>
85<li>
86The VM is complete in the sense that it <b>should</b> run all Lua code
87just fine. It's considered a serious bug if the VM crashes or produces
88unexpected results &mdash; please report it. There are only very few
89known incompatibilities with standard Lua:
90<ul>
91<li>
92The Lua <b>debug API</b> is missing a couple of features (call/return
93hooks) and shows slightly different behavior (no per-coroutine hooks).
94</li>
95<li>
96Most other issues you're likely to find (e.g. with the existing test
97suites) are differences in the <b>implementation-defined</b> behavior.
98These either have a good reason (like early tail call resolving which
99may cause differences in error reporting), are arbitrary design choices
100or are due to quirks in the VM. The latter cases may get fixed if a
101demonstrable need is shown.
102</li>
103</ul>
104</li>
105<li>
106The <b>JIT compiler</b> is not complete (yet) and falls back to the
107interpreter in some cases. All of this works transparently, so unless
108you use -jv, you'll probably never notice (the interpreter is quite
109fast, too). Here are the known issues:
110<ul>
111<li>
112Many known issues cause a <b>NYI</b> (not yet implemented) trace abort
113message. E.g. for calls to vararg functions or many string library
114functions. Reporting these is only mildly useful, except if you have good
115example code that shows the problem. Obviously, reports accompanied with
116a patch to fix the issue are more than welcome. But please check back
117with me, before writing major improvements, to avoid duplication of
118effort.
119</li>
120<li>
121<b>Recursion</b> is not traced yet. Often no trace will be generated at
122all or some unroll limit will catch it and aborts the trace.
123</li>
124<li>
125The trace compiler currently does not back off specialization for
126function call dispatch. It should really fall back to specializing on
127the prototype, not the closure identity. This can lead to the so-called
128"trace explosion" problem with <b>closure-heavy programming</b>. The
129trace linking heuristics prevent this, but in the worst case this
130means the code always falls back to the interpreter.
131</li>
132<li>
133<b>Trace management</b> needs more tuning: better blacklisting of aborted
134traces, less drastic countermeasures against trace explosion and better
135heuristics in general.
136</li>
137<li>
138Some checks are missing in the JIT-compiled code for obscure situations
139with <b>open upvalues aliasing</b> one of the SSA slots later on (or
140vice versa). Bonus points, if you can find a real world test case for
141this.
142</li>
143</ul>
144</li>
145</ul>
146
147<h2>Roadmap</h2>
148<p>
149Rather than stating exact release dates (I'm well known for making
150spectacularly wrong guesses), this roadmap lists the general project
151plan, sorted by priority, as well as ideas for the future:
152</p>
153<ul>
154<li>
155The main goal right now is to stabilize LuaJIT 2.0 and get it out of
156beta test. <b>Correctness</b> has priority over completeness. This
157implies the first stable release will certainly NOT compile every
158library function call and will fall back to the interpreter from time
159to time. This is perfectly ok, since it still executes all Lua code,
160just not at the highest possible speed.
161</li>
162<li>
163The next step is to get it to compile more library functions and handle
164more cases where the compiler currently bails out. This doesn't mean it
165will compile every corner case. It's much more important that it
166performs well in a majority of use cases. Every compiler has to make
167these trade-offs &mdash; <b>completeness</b> just cannot be the
168overriding goal for a low-footprint, low-overhead JIT compiler.
169</li>
170<li>
171More <b>optimizations</b> will be added in parallel to the last step on
172an as-needed basis. Array-bounds-check (ABC) removal, sinking of stores
173to aggregates and sinking of allocations are high on the list. Faster
174handling of NEWREF and better alias analysis are desirable, too. More
175complex optimizations with less pay-off, such as value-range-propagation
176(VRP) will have to wait.
177</li>
178<li>
179LuaJIT 2.0 has been designed with <b>portability</b> in mind.
180Nonetheless, it compiles to native code and needs to be adapted to each
181architecture. Porting the compiler backend is probably the easier task,
182but a key element of its design is the fast interpreter, written in
183machine-specific assembler.<br>
184The code base and the internal structures are already prepared for
185easier porting to 64 bit architectures. The most likely next target is a
186port to <b>x64</b>, but this will have to wait until the x86 port
187stabilizes. Other ports will follow &mdash; companies which are
188interested in sponsoring a port to a particular architecture, please
189<a href="contact.html">contact me</a>.
190</li>
191<li>
192There are some planned <b>structural improvements</b> to the compiler,
193like compressed snapshot maps or generic handling of calls to helper
194methods. These are of lesser importance, unless other developments
195elevate their priority.
196</li>
197<li>
198<b>Documentation</b> about the <b>internals</b> of LuaJIT is still sorely
199missing. Although the source code is included and is IMHO well
200commented, many basic design decisions are in need of an explanation.
201The rather un-traditional compiler architecture and the many highly
202optimized data structures are a barrier for outside participation in
203the development. Alas, as I've repeatedly stated, I'm better at
204writing code than papers and I'm not in need of any academical merits.
205Someday I will find the time for it. :-)
206</li>
207<li>
208Producing good code for unbiased branches is a key problem for trace
209compilers. This is the main cause for "trace explosion".
210<b>Hyperblock scheduling</b> promises to solve this nicely at the
211price of a major redesign of the compiler. This would also pave the
212way for emitting predicated instructions, which is a prerequisite
213for efficient <b>vectorization</b>.
214</li>
215<li>
216Currently Lua is missing a standard library for access to <b>structured
217binary data</b> and <b>arrays/buffers</b> holding low-level data types.
218Allowing calls to arbitrary C functions (<b>FFI</b>) would obviate the
219need to write manual bindings. A variety of extension modules is floating
220around, with different scope and capabilities. Alas, none of them has been
221designed with a JIT compiler in mind.
222</li>
223</ul>
224<br class="flush">
225</div>
226<div id="foot">
227<hr class="hide">
228Copyright &copy; 2005-2009 Mike Pall
229<span class="noprint">
230&middot;
231<a href="contact.html">Contact</a>
232</span>
233</div>
234</body>
235</html>
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-01-12 01:15:18 +0000