观察者:Lua JIT详解（观察者the one）

自从 OpenResty 1.5.8.1 版本之后，默认捆绑的 Lua 解释器就被替换成了 LuaJIT，而不再是标准 Lua。单从名字上，我们就可以直接看到这个新的解释器多了一个 JIT ，接下来我们就一起来聊聊 JIT 。

先看一下 LuaJIT 官方的解释：LuaJIT is a Just-In-Time Compilerfor the Lua programming language。

LuaJIT 的运行时环境包括一个用手写汇编实现的 Lua 解释器和一个可以直接生成机器代码的JIT 编译器。

Lua 代码在被执行之前总是会先被 lfn 成 LuaJIT 自己定义的字节码（Byte Code） 。

一开始的时候，Lua 字节码总是被 LuaJIT 的解释器解释执行。LuaJIT 的解释器会在执行字节码时同时记录一些运行时的统计信息，比如每个 Lua 函数调用入口的实际运行次数，还有每个 Lua 循环的实际执行次数。当这些次数超过某个预设的阈值时，便认为对应的 Lua 函数入口或者对应的 Lua 循环足够的“热”，这时便会触发 JIT 编译器开始工作。

JIT 编译器会从热函数的入口或者热循环的某个位置开始尝试编译对应的 Lua 代码路径。编译的过程是把 LuaJIT 字节码先转换成LuaJIT 自己定义的中间码（IR） ，然后再生成针对目标体系结构的机器码（比如 x86_64 指令组成的机器码） 。

如果当前 Lua 代码路径上的所有的操作都可以被 JIT 编译器顺利编译，则这条编译过的代码路径便被称为一个“trace”，在物理上对应一个 trace 类型的 GC 对象（即参与 Lua GC 的对象） 。

你可以通过 ngx-lj-gc-objs 工具看到指定的 Nginx worker 进程里所有 trace 对象的一些基本的统计信息,

比如下面这一行 ngx-lj-gc-objs 工具的输出

102 trace objects: max=928, avg=337, min=160, sum=34468 (in bytes)

则表明当前进程内的 LuaJIT VM 里一共有 102 个 trace 类型的 GC 对 象，其中最小的 trace占用 160 个字节，最大的占用 928 个字节，平均大小是 337 字节，而所有 trace 的总大小是34468 个字节。

LuaJIT 的 JIT 编译器的实现目前还不完整，有一些基本原语它还无法编译，比如 pairs() 函数、unpack() 函数、string.match() 函数、基于 lua_CFunction 实现的 Lua C 模块、FNEW字节码，等等。所以当 JIT 编译器在当前代码路径上遇到了它不支持的操作，便会立即终止当前的 trace 编译过程（这被称为 trace abort） ，而重新退回到解释器模式。

JIT 编译器不支持的原语被称为 NYI（Not Yet Implemented） 原语。

所谓“让更多的 Lua 代码被 JIT 编译”，其实就是帮助更多的 Lua 代码路径能为 JIT 编译器所接受。这一般通过两种途径来实现：

1. 调整对应的 Lua 代码，避免使用 NYI 原语。

2. 增强 JIT 编译器，让越来越多的 NYI 原语能够被编译。

对于第 2 种方式，春哥一直在推动公司（CloudFlare） 赞助 Mike Pall 的开发工作。不过有些原语因为本身的代价过高，而永远不会被编译，比如基于经典的 lua_CFunction 方式实现的Lua C 模块（所以需要尽量通过 LuaJIT 的 FFI 来调用 C） 。

而对于第 1 种方法，我们如何才能知道具体是哪一行 Lua 代码上的哪一个 NYI 原语终止了trace 编译呢？答案很简单。就是使用 LuaJIT 安装自带的 jit.v 和 jit.dump 这两个 Lua 模块。

这两个 Lua 模块会打印出 JIT 编译器工作的细节过程。

在 Nginx 的上下文中，我们可以在 nginx.conf 文件中的 http {} 配置块中添加下面这一段：

init_by_lua_block {

local verbose = false

if verbose then

local dump = require "jit.dump"

dump.on(nil, "/tmp/jit.log")

else

local v = require "jit.v"

v.on("/tmp/jit.log")

end

require "resty.core"

}

那一行 require "resty.core" 倒并不是必需的，放在那里的主要目的是为了尽量避免使用ngx_lua 模块自己的基于 lua_CFunction 的 Lua API，减少 NYI 原语。

在上面这段 Lua 代码中，当 verbose 变量为 false 时（默认就为 false 哈） ，我们使用 jit.v 模块打印出比较简略的流水信息到 /tmp/jit.log 文件中；而当 verbose 变量为 true 时，我们则使用 jit.dump 模块打印所有的细节信息，包括每个 trace 内部的字节码、IR 码和最终生成的机器指令。

这里我们主要以 jit.v 模块为例。在启动 Nginx 之后，应当使用 ab 和 weighttp 这样的工具对相应的服务接口进行预热，以触发 LuaJIT 的 JIT 编译器开始工作（还记得刚才我们说的“热函数”和“热循环”吗？） 。预热过程一般不用太久，跑个二三百个请求足矣。当然，压更多的请求也没关系。完事后，我们就可以检查 /tmp/jit.log 文件里面的输出了。

jit.v 模块的输出里如果有类似下面这种带编号的 TRACE 行，则指示成功编译了的 trace 对象，例如

[TRACE 6 shdict.lua:126 return]

这个 trace 对象编号为 6，对应的 Lua 代码路径是从 shdict.lua 文件的第 126 行开始的。

下面这样的也是成功编译了的 trace:

[TRACE 16 (15/1) waf-core.lua:419 -> 15]

这个 trace 编号为 16，是从 waf-core.lua 文件的第 419 行开始的，同时它和编号为 15 的trace 联接了起来。

而下面这个例子则是被中断的 trace:

[TRACE --- waf-core.lua:455 -- NYI: FastFunc pairs at waf-core.lua:458]

上面这一行是说，这个 trace 是从 waf-core.lua 文件的第 455 行开始编译的，但当编译到waf-core.lua 文件的第 458 行时，遇到了一个 NYI 原语编译不了，即 pairs() 这个内建函数，于是当前的 trace 编译过程被迫终止了。

类似的例子还有下面这些：

[TRACE --- exit.lua:27 -- NYI: FastFunc coroutine.yield at waf-core.lua:439]

[TRACE --- waf.lua:321 -- NYI: bytecode 51 at raven.lua:107]

上面第二行是因为操作码 51 的 LuaJIT 字节码也是 NYI 原语，编译不了。

那么我们如何知道 51 字节码究竟是啥呢？我们可以用 nginx-devel-utils 项目中的 ljbc.lua 脚本来取得 51 号字节码的名字：

$ /usr/local/openresty/luajit/bin/luajit-2.1.0-alpha ljbc.lua 51

opcode 51:

FNEW

我们看到原来是用来（动态） 创建 Lua 函数的 FNEW 字节码。ljbc.lua 脚本的位置是https://github.com/agentzh/nginx-devel-utils/blob/master/ljbc.lua

非常简单的一个脚本，就几行 Lua 代码。

这里需要提醒的是，不同版本的 LuaJIT 的字节码可能是不相同的，所以一定要使用和你的Nginx 链接的同一个 LuaJIT 来运行这个 ljbc.lua 工具，否则有可能会得到错误的结果。

我们实际做个对比实验，看看 JIT 带来的好处：

? cat test.lua

local s = [[aaaaaabbbbbbbcccccccccccddddddddddddeeeeeeeeeeeee

fffffffffffffffffggggggggggggggaaaaaaaaaaabbbbbbbbbbbbbb

ccccccccccclllll]]

for i=1,10000 do

for j=1,10000 do

string.find(s, "ll", 1, true)

end

end

? time luajit test.lua

5.19s user

0.03s system

96% cpu

5.392 total

? time lua test.lua

9.20s user

0.02s system

99% cpu

9.270 total

本例子可以看到效率相差大约 9.2/5.19 ≈ 1.77 倍，换句话说标准 Lua 需要 177% 的时间才能完成同样的工作。估计大家觉得这个还不过瘾，再看下面示例代码：

文件 test.lua：

local loop_count = tonumber(arg[1])

local fun_pair = "ipairs" == arg[2] and ipairs or pairs

local t = {}

for i=1,100 do

t[i] = i

end

for i=1,loop_count do

for j=1,1000 do

for k,v in fun_pair(t) do

--

end

end

end

执行参数执行结果

time lua test.lua 1000 ipairs 3.96s user 0.02s system 98% cpu 4.039 total

time lua test.lua 1000 pairs 3.97s user 0.01s system 99% cpu 3.992 total

time luajit test.lua 1000 ipairs 0.10s user 0.00s system 95% cpu 0.113 total

time luajit test.lua 10000 ipairs 0.98s user 0.00s system 99% cpu 0.991 total

time luajit test.lua 1000 pairs 1.54s user 0.01s system 99% cpu 1.559 total

从这个执行结果中，大致可以总结出下面几个观点：

在标准 Lua 解释器中，使用 ipairs 或 pairs 没有区别；

对于 pairs 方式，LuaJIT 的性能大约是标准 Lua 的 4 倍；

对于 ipairs 方式，LuaJIT 的性能大约是标准 Lua 的 40 倍。

可以被 JIT 编译的元操作

下面给大家列一下截止到目前已经可以被 JIT 编译的元操作。 其他还有 IO、Bit、FFI、Coroutine、OS、Package、Debug、JIT 等分类，使用频率相对较低，这里就不罗列了。

基础库的支持情况

函数 编译? 备注

assert yes

collectgarbage no

dofile never

error never

getfenv 2.1 partial 只有 getfenv(0) 能编译

getmetatable yes

ipairs yes

load never

loadfile never

loadstring never

next no

pairs no

pcall yes

print no

rawequal yes

rawget yes

rawlen (5.2) yes

rawset yes

select partial 第一个参数是静态变量的时候可以编译

setfenv no

setmetatable yes

tonumber partial 不能编译非10进制，非预期的异常输入

tostring partial 只能编译：字符串、数字、布尔、nil 以及支持 __tostring元方法的类型

type yes

unpack no

xpcall yes

字符串库

函数 编译? 备注

string.byte yes

string.char 2.1

string.dump never

string.find 2.1 partial 只有字符串样式查找（没有样式）

string.format 2.1 partial 不支持 %p 或 非字符串参数的 %s

string.gmatch no

string.gsub no

string.len yes

string.lower 2.1

string.match no

string.rep 2.1

string.reverse 2.1

string.sub yes

string.upper 2.1

表

函数 编译? 备注

table.concat 2.1

table.foreach no 2.1: 内部编译，但还没有外放

table.foreachi 2.1

table.getn yes

table.insert partial 只有 push 操作

table.maxn no

table.pack (5.2) no

table.remove 2.1 部分，只有 pop 操作

table.sort no

table.unpack (5.2) no

math 库

函数 编译? 备注

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