Not Yet Implemented

All aspects of Lua are implemented in LuaJIT's interpreter, but not all of them are implemented in LuaJIT's JIT compiler. This page serves as a quick reference to identify whether certain things are implemented or not. Hopefully meaning that you can avoid them in performance-critical code rather than puzzle over why you're seeing poorly performing code and NYI messages from -jv.

Note that the goal of LuaJIT is not only to produce fast code, but to have a fast and compact JIT compiler, too. It's not a stated goal to compile everything, since the interpreter is fast enough for many tasks. And speed doesn't matter for anything that's done only a couple of times during the runtime of a program. E.g. it would be absolutely pointless to compile require() or module() (in fact, these should eventually be rewritten as plain Lua functions).

However, the number of JIT-compiled cases will grow over time, based on demand and user feedback.

The following tables provide an indication whether a feature is JIT-compiled or not:

• yes - Always JIT-compiled.
• partial - May be JIT-compiled, depending on the circumstances. Otherwise will fall back to the interpreter.
• no - Not JIT-compiled (yet), will always fall back to the interpreter.
• NO - Ditto. Will not be JIT-compiled, even in future versions.

Outlook on LuaJIT 2.1

The New Garbage Collector planned for LuaJIT 2.1 will have support for in-place movable/resizable buffer objects. This will allow compilation of CAT, string.* and table.concat.

Many of the remaining NYI library functions may be rewritten as plain Lua functions with the help of special bytecodes. These can then be compiled like any other Lua function.

Bytecode

Almost all bytecodes are compiled, except for these:

Bytecode	Compiled?	Remarks
CAT	no	Concatenation operator '..'.
FNEW	no	Create closure.
FUNCC	NO	Call C function via classic API.
FUNCCW	NO	Call wrapped C function via classic API.
FUNC*	partial	Call built-in function. See below.
ISNEXT	no	Check for next() loop optimization.
ITERN	no	Optimized call to next() in loop.
CALLT	partial	Tailcall. Some tailcalls to frames lower than the starting frame of the trace are not compiled.
RET*	partial	Return from function. Returns to C frames and some returns to frames lower than the starting frame of the trace are not compiled.
TSETM	no	Initialize table with multiple return values.
UCLO	no	Close upvalues.
VARG	partial	Vararg operator '...'. Multi-result VARG is only compiled when used with select().

Notes:

• Table accesses to mixed dense/sparse tables are not compiled.
• Bytecode execution that would cause an error in the interpreter is never compiled.

Libraries

The following tables list whether or not calls to the various built-in library functions will get compiled. This may depend on the arguments passed (esp. their types) and the exact circumstances of the call.

Base Library

Function	Compiled?	Remarks
assert	yes
collectgarbage	no
dofile	NO
error	NO
getfenv	no
getmetatable	yes
ipairs	yes
load	NO
loadfile	NO
loadstring	NO
next	no
pairs	no
pcall	yes
print	no
rawequal	yes
rawget	yes
rawlen (5.2)	yes
rawset	yes
select	partial	Only compiled when first argument is a constant.
setfenv	no
setmetatable	yes
tonumber	partial	Won't compile for bases other than 10, other exceptions apply.
tostring	partial	Only compiled for strings, numbers, booleans, nil, and values with a __tostring metamethod.
type	yes
unpack	no
xpcall	yes

String Library

Function	Compiled?	Remarks
string.byte	yes
string.char	no
string.dump	NO
string.find	no
string.format	no
string.gmatch	no
string.gsub	no
string.len	yes
string.lower	no
string.match	no
string.rep	no
string.reverse	no
string.sub	yes
string.upper	no

Table Library

Function	Compiled?	Remarks
table.concat	no
table.foreach	no
table.foreachi	no
table.getn	yes
table.insert	partial	Only when pushing.
table.maxn	no
table.pack (5.2)	no
table.remove	partial	Only when popping.
table.sort	no
table.unpack (5.2)	no

Math Library

Function	Compiled?	Remarks
math.abs	yes
math.acos	yes
math.asin	yes
math.atan	yes
math.atan2	yes
math.ceil	yes
math.cos	yes
math.cosh	yes
math.deg	yes
math.exp	yes
math.floor	yes
math.fmod	no
math.frexp	no
math.ldexp	yes
math.log	yes
math.log10	yes
math.max	yes
math.min	yes
math.modf	yes
math.pow	yes
math.rad	yes
math.random	yes
math.randomseed	no
math.sin	yes
math.sinh	yes
math.sqrt	yes
math.tan	yes
math.tanh	yes

IO Library

Function	Compiled?	Remarks
io.close	no
io.flush	yes
io.input	no
io.lines	no
io.open	no
io.output	no
io.popen	no
io.read	no
io.tmpfile	no
io.type	no
io.write	yes

Bit Library

Function	Compiled?	Remarks
bit.arshift	yes
bit.band	yes
bit.bnot	yes
bit.bor	yes
bit.bswap	yes
bit.bxor	yes
bit.lshift	yes
bit.rol	yes
bit.ror	yes
bit.rshift	yes
bit.tobit	yes
bit.tohex	no

FFI Library

Function	Compiled?	Remarks
ffi.alignof	yes
ffi.abi	yes
ffi.cast	partial	Same restrictions as ffi.new (casting is a form of cdata creation).
ffi.cdef	NO
ffi.copy	yes
ffi.errno	partial	Not when setting a new value.
ffi.fill	yes
ffi.gc	partial	Not when clearing a finalizer.
ffi.istype	yes
ffi.load	NO
ffi.metatype	NO
ffi.new	partial	Not when the allocation is for more than 128 bytes, other exceptions apply.
ffi.offsetof	yes
ffi.sizeof	partial	Not for VLA/VLS types (see below).
ffi.string	yes
ffi.typeof	partial	Only for cdata arguments. NO for cdecl strings.

For more details see the current implementation status of the FFI library.

Note: Avoid ffi.sizeof(cdata) for variable-length types (VLA/VLS). This call is not compiled and may become a rather expensive operation with the New Garbage Collector, since the actual length may not be stored inside the cdata object anymore.

Coroutine Library

No functions are compiled.

OS Library

No functions are compiled.

Package Library

No functions are compiled (NO).

Debug Library

No functions are compiled (NO).

JIT Library

No functions are compiled (NO).