| blob | d386e1aa5db6a2fa6f906c98a15f74418001d796 |
2 <html>
3 <head>
13 </style>
14 </head>
15 <body>
18 </div>
21 </div>
23 <ul><li>
25 <ul><li>
27 </li><li>
29 </li></ul>
30 </li><li>
32 <ul><li>
34 <ul><li>
36 </li><li>
38 </li><li>
40 </li></ul>
41 </li><li>
43 </li><li>
45 </li></ul>
46 </li><li>
48 <ul><li>
50 </li></ul>
51 </li><li>
53 </li><li>
55 </li><li>
57 </li></ul>
58 </div>
60 <p>
63 Only a single bug has been discovered in the last two years. So, if
64 you need a rock-solid VM, you are encouraged to fetch the latest
65 release of LuaJIT 1.x from the <a href="http://luajit.org/download.html"><span class="ext">»</span> Download</a>
66 page.
67 </p>
68 <p>
72 substantial changes.
73 It has <a href="http://luajit.org/performance.html"><span class="ext">»</span> much better performance</a> than LuaJIT 1.x.
74 It's maturing quickly, so you should definitely
75 start to evaluate it for new projects right now.
76 </p>
79 <p>
80 This is a list of the things you should know about the LuaJIT 2.0 beta test:
81 </p>
82 <ul>
83 <li>
85 rewritten from the ground up. Please report your findings together with
86 the circumstances needed to reproduce the bug. If possible, reduce the
87 problem down to a simple test case.<br>
88 There is no formal bug tracker at the moment. The best place for
89 discussion is the
90 <a href="http://www.lua.org/lua-l.html"><span class="ext">»</span> Lua mailing list</a>. Of course
92 especially when they contain lengthy debug output or if you require
93 confidentiality.
94 </li>
95 <li>
96 The x86 JIT compiler only generates code for CPUs with support for
98 Atom or K8/K10 to get the full benefit.<br>
99 If you run LuaJIT on older CPUs without SSE2 support, the JIT compiler
100 is disabled and the VM falls back to the LuaJIT interpreter. This is faster
101 than the Lua interpreter, but not nearly as fast as the JIT compiler of course.
102 Run the command line executable without arguments to show the current status
104 </li>
105 <li>
107 just fine. It's considered a serious bug if the VM crashes or produces
108 unexpected results — please report this. There are only very few
109 known incompatibilities with standard Lua:
110 <ul>
111 <li>
113 hooks for non-Lua functions) and shows slightly different behavior
114 (no per-coroutine hooks, no tail call counting).
115 </li>
116 <li>
118 <ul>
121 to enable line editing. It's planned to add support for loading it
122 on-demand.</li>
123 </ul>
124 </li>
125 <li>
126 Most other issues you're likely to find (e.g. with the existing test
128 These either have a good reason (like early tail call resolving which
129 may cause differences in error reporting), are arbitrary design choices
130 or are due to quirks in the VM. The latter cases may get fixed if a
131 demonstrable need is shown.
132 </li>
133 </ul>
134 </li>
135 <li>
137 interpreter in some cases. All of this works transparently, so unless
139 <a href="http://luajit.org/performance.html"><span class="ext">»</span> quite fast</a>, too). Here are the known issues:
140 <ul>
141 <li>
143 message. E.g. for calls to some internal library
144 functions. Reporting these is only mildly useful, except if you have good
145 example code that shows the problem. Obviously, reports accompanied with
146 a patch to fix the issue are more than welcome. But please check back
147 with me, before writing major improvements, to avoid duplication of
148 effort.
149 </li>
150 <li>
151 The trace compiler currently doesn't back off specialization for
152 function call dispatch. It should really fall back to specializing on
153 the prototype, not the closure identity. This can lead to the so-called
155 trace linking heuristics prevent this, but in the worst case this
156 means the code always falls back to the interpreter.
157 </li>
158 <li>
160 against trace explosion and better heuristics in general.
161 </li>
162 <li>
163 Some checks are missing in the JIT-compiled code for obscure situations
165 vice versa). Bonus points, if you can find a real world test case for
166 this.
167 </li>
168 <li>
170 handled correctly. The error may fall through an on-trace
173 </li>
174 </ul>
175 </li>
176 </ul>
179 <p>
180 Please refer to the
181 <a href="http://lua-users.org/lists/lua-l/2011-01/msg01238.html"><span class="ext">»</span> LuaJIT
183 project plan for LuaJIT 2.0:
184 </p>
185 <ul>
186 <li>
187 The main goal right now is to stabilize LuaJIT 2.0 and get it out of
189 implies the first stable release will certainly NOT compile every
190 library function call and will fall back to the interpreter from time
191 to time. This is perfectly ok, since it still executes all Lua code,
192 just not at the highest possible speed.
193 </li>
194 <li>
195 The next step is to get it to compile more library functions and handle
196 more cases where the compiler currently bails out. This doesn't mean it
197 will compile every corner case. It's much more important that it
198 performs well in a majority of use cases. Every compiler has to make
200 overriding goal for a low-footprint, low-overhead JIT compiler.
201 </li>
202 <li>
204 an as-needed basis. Sinking of stores
205 to aggregates and sinking of allocations are high on the list.
206 More complex optimizations with less pay-off, such as value-range-propagation
207 (VRP) will have to wait.
208 </li>
209 <li>
211 Nonetheless, it compiles to native code and needs to be adapted to each
212 architecture. The two major work items are porting the the fast interpreter,
213 which is written in assembler, and porting the compiler backend.
215 have already been taken care of.<br>
216 Several ports are already available, thanks to the
217 <a href="http://luajit.org/sponsors.html"><span class="ext">»</span> LuaJIT sponsorship program</a>.
218 More ports will follow in the future — companies which are
219 interested in sponsoring a port to a particular architecture, please
220 use the given contact address.
221 </li>
222 <li>
224 missing. Although the source code is included and is IMHO well
225 commented, many basic design decisions are in need of an explanation.
226 The rather un-traditional compiler architecture and the many highly
227 optimized data structures are a barrier for outside participation in
228 the development. Alas, as I've repeatedly stated, I'm better at
229 writing code than papers and I'm not in need of any academic merits.
230 Someday I will find the time for it. :-)
231 </li>
232 <li>
233 Producing good code for unbiased branches is a key problem for trace
234 compilers. This is the main cause for "trace explosion".
236 price of a major redesign of the compiler. This would also pave the
237 way for emitting predicated instructions, which is a prerequisite
239 </li>
240 </ul>
242 </div>
247 ·
249 </span>
250 </div>
251 </body>
252 </html>