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