lua gc分析

发表于 2018-06-17 更新于 2022-06-25 阅读次数：

说明

分析lua使用的gc算法，如何做到分步gc，以及测试结论

gc算法分析

lua gc采用的是标记-清除算法，即一次gc分两步：

从根节点开始遍历gc对象，如果可达，则标记
遍历所有的gc对象，清除没有被标记的对象

二色标记法

lua 5.1之前采用的算法，二色回收法是最简单的标记-清除算法，缺点是gc的时候不能被打断，所以会严重卡住主线程

三色标记法

lua5.1开始采用了一种三色回收的算法
- 白色：在gc开始阶段，所有对象颜色都为白色，如果遍历了一遍之后，对象还是白色的将被清除
- 灰色：灰色用在分步遍历阶段，如果一直有对象为灰色，则遍历将不会停止
- 黑色：确实被引用的对象，将不会被清除，gc完成之后会重置为白色
luajit使用状态机来执行gc算法，共有6中状态：
- GCSpause：gc开始阶段，初始化一些属性，将一些跟节点（主线程对象，主线程环境对象，全局对象等）push到灰色链表中
- GCSpropagate：分步进行扫描，每次从灰色链表pop一个对象，遍历该对象的子对象，例如如果该对象为table，并且value没有设置为week，则会遍历table所有table可达的value，如果value为gc对象且为白色，则会被push到灰色链表中，这一步将一直持续到灰色链表为空的时候。
- GCSatomic：原子操作，因为GCSpropagate是分步的，所以分步过程中可能会有新的对象创建，这时候将再进行一次补充遍历，这遍历是不能被打断的，但因为绝大部分工作被GCSpropagate做了，所以过程会很快。新创建的没有被引用的userdata，如果该userdata自定义了gc元方法，则会加入到全局的userdata链表中，该链表会在最后一步GCSfinalize处理。
- GCSsweepstring：遍历全局字符串hash表，每次遍历一个hash节点，如果hash冲突严重，会在这里影响gc。如果字符串为白色并且没有被设置为固定不释放，则进行释放
- GCSsweep：遍历所有全局gc对象，每次遍历40个，如果gc对象为白色，将被释放
- GCSfinalize：遍历GCSatomic生成的userdata链表，如果该userdata还存在gc元方法，调用该元方法，每次处理一个

什么时候会导致gc?

luajit中有两个判断是否需要gc的宏，如果需要gc，则会直接进行一次gc的step操作

/* GC check: drive collector forward if the GC threshold has been reached. */
#define lj_gc_check(L) \
  { if (LJ_UNLIKELY(G(L)->gc.total >= G(L)->gc.threshold)) \
      lj_gc_step(L); }
#define lj_gc_check_fixtop(L) \
  { if (LJ_UNLIKELY(G(L)->gc.total >= G(L)->gc.threshold)) \
      lj_gc_step_fixtop(L); }

gc.total: 代表当前已经申请的内存
gc.threshold：代表当前设置gc的阈值

这两个宏会在各个申请内存的地方进行调用，所以当前申请的内存如果已经达到设置的阈值，则会申请的所有对象都会有gc消耗。

lua gc api

lua可以通过

1	collectgarbage([opt [, arg]])

来进行一些gc操作，其中opt参数可以为：

“collect”：执行一个完整的垃圾回收周期，这是一个默认的选项
“stop”：停止垃圾收集器（如果它在运行），实现方式其实就是将gc.threshold设置为一个巨大的值，不再触发gc step操作
“restart”：将重新启动垃圾收集器（如果它已经停止）。
“count”：返回当前使用的的程序内存量（单位是Kbytes），返回gc->total/1024
“step”：执行垃圾回收的步骤，这个步骤的大小由参数arg（较大的数值意味着较多的步骤），如果这一步完成了一个回收周期则函数返回true。
“setpause”：设置回收器的暂停参数，并返回原来的暂停数值。该值是一个百分比，影响gc.threshold的大小，即影响触发下一次gc的时间，设置代码如下：
1
g->gc.threshold = (g->gc.estimate/100) * g->gc.pause;
g->gc.estimate为当前实际使用的内存的大小，如果gc.pause为200，则该段代码表示，设置gc的阈值为当前实际使用内存的2倍
“setstepmul”：设置回收器的步进乘数，并返回原值。该值代表每次自动step的步长倍率，影响每次gc step的速率，具体这么影响可以查看后面小节

luajit gc速率控制

int LJ_FASTCALL lj_gc_step(lua_State *L)
{
  global_State *g = G(L);
  GCSize lim;
  int32_t ostate = g->vmstate;
  setvmstate(g, GC);
  // 设置此次遍历的限制值，每次调用gc_onestep都会返回此次step的消耗，限制值消耗完毕之后此次step结束;
  lim = (GCSTEPSIZE/100) * g->gc.stepmul;
  if (lim == 0)
    lim = LJ_MAX_MEM;
  if (g->gc.total > g->gc.threshold)
    g->gc.debt += g->gc.total - g->gc.threshold;
  do {
    lim -= (GCSize)gc_onestep(L);
    if (g->gc.state == GCSpause) {
      g->gc.threshold = (g->gc.estimate/100) * g->gc.pause;
      g->vmstate = ostate;
      return 1;  /* Finished a GC cycle. */
    }
  } while (sizeof(lim) == 8 ? ((int64_t)lim > 0) : ((int32_t)lim > 0));
  if (g->gc.debt < GCSTEPSIZE) {
    g->gc.threshold = g->gc.total + GCSTEPSIZE;
    g->vmstate = ostate;
    return -1;
  } else {
    // 加快内存上涨速度;
    g->gc.debt -= GCSTEPSIZE;
    g->gc.threshold = g->gc.total;
    g->vmstate = ostate;
    return 0;
  }
}

可以看到最重要的变量为lim，该变量控制着一个lj_gc_step里的循环次数。每次调用gc_onestep都会返回此次的step消耗，例如如果处于GCSpropagate阶段，则返回值为该step遍历的内存大小，所以如果遍历了一个较大的table就会消耗更多的lim值
lim大小主要由gc.stepmul控制，所以设置该值的大小会影响每次step的调用时间

测试大table对gc的影响

从luajit gc原理上看，以为每次gc的遍历都会遍历所有的gc对象，所以大的table是会影响gc性能

测试环境

操作系统：Debian GNU/Linux 8
CPU：Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz
内存：64G
lua环境：LuaJIT-2.1.0-beta3 (测试的时候关闭jit)

测试代码

-- 关闭jit
if jit then
    jit.off()
end

local data = {} -- 一个大的table，用来模拟常驻内存的table，测试的时候使用的是drop_data.lua里面的数据，该data有8655个table元素（在gc的时候产生消耗），60810个元素（包括table元素，会在遍历的时候产生消耗）

function deepCopyTable(t)
    local ret = {}
    for k, v in pairs(t) do
        if type(v) == "table" then
            ret[k] = deepCopyTable(v)
        else
            ret[k] = v
        end
    end
    return ret
end

datas = {}

-- 循环产生更多的常驻内存的table，可以看到总共会有865W+的table元素和总共6000W+的元素
for i = 1, 1000 do
	datas[#datas+1] = deepCopyTable(data)
end

print("begin")
local time = os.clock()
for i = 1, 2000000 do
    -- 模拟产生临时变量
	local temp = deepCopyTable(data)

    -- 每10次计算一次时间和内存
	if i % 10 == 0 then
		local time_temp = os.clock()
		print(collectgarbage("count"), time_temp-time)
		time = time_temp
	end
end

测试结果（第一个列为当前内存，第二列为当前内存阈值，第三列为当前gc状态，第四列为循环10次的时间）

-- gc没有介入阶段，平均时间大概在0.059s，这时候代表着内存的分配速度
3345733.2617188	4136590.0390625	0	0.058304
3366347.6367188	4136590.0390625	0	0.058013000000003
3386962.0117188	4136590.0390625	0	0.058147999999996
3407576.3867188	4136590.0390625	0	0.059978000000001
3428190.7617188	4136590.0390625	0	0.059843999999998
3448805.1367188	4136590.0390625	0	0.058331000000003
3469419.5117188	4136590.0390625	0	0.058205000000001
3490033.8867188	4136590.0390625	0	0.058352999999997
3510648.2617188	4136590.0390625	0	0.058503000000002
3531262.6367188	4136590.0390625	0	0.058151000000002
3551877.0117188	4136590.0390625	0	0.058059999999998

-- gc进入sweep阶段，删除内存，峰值时间在0.78s左右，后面时间变少应该是因为那一块都是常驻内存的gc对象，很少会去调用free函数
5056726.3867188	5056726.3242188	1	0.076171000000002
5077340.7617188	5077340.9492188	1	0.076453999999998
4955367.8554688	4955368.0429688	4	0.140509
3994134.0820313	3994134.0195313	4	0.679567
3032849.7617188	3032850.1992188	4	0.786561
2133608.0117188	2133608.7617188	4	0.788004
2154222.3867188	2154222.3242188	4	0.255904
2174836.7617188	2174837.1992188	4	0.254212
full sweep time: 2.850359
2195451.1367188	4137406.4453125	0	0.066203999999999

火焰图分析（gc处于sweep状态）：

主要时间消耗在gc_sweep(51.34%)：该步骤会遍历所有的gc对象，如果可回收，就进行free操作，所以gc_sweep里面最耗时的就是free函数(34%左右)

gc优化

从火焰图上看到，gc_sweep函数耗时严重，其主要工作是遍历所有gc对象，如果为白色，则free它，所以优化方案有两点：

内存分配算法优化
减少gc遍历的对象，即减少那些明确常驻内存的gc对象遍历

内存分配算法优化

luajit默认使用的是自己的内存分配算法，现在尝试分别使用glibc自带的内存分配和第三方高性能jemalloc（选择的版本是jemalloc-stable-4），tcmalloc（选择的是gperftools-2.7）的分配算法进行分析

测试结果

结果分析

申请内存的速率跟常驻内存的table大小关系不大，luajit自带的分配算法最快，但是总体相差不大
随着常驻内存的table大小变大，会影响gc释放速度，这将会卡主主线程
释放内存速率jemalloc最好，并且随着常驻内存的table大小变大，效率体现的越明显

table缓存优化

思路

自己写一个table缓冲池，缓冲一定数量、一定大小的table在c++内存，避免每次反复申请内存及rehash，reszie table操作
TODO: 需要具体修改luajit源码进行测试

减少gc遍历的对象

思路

对于那些常驻内存的table，可以主动加一个标记，在gc时候遍历到这个table，将对其以及所有子gc对象从全局gc链表删除，并加入到一个全局const gc对象链表中。
源代码可以查看github

测试结果

对比结果

火焰图（jemalloc-4G内存）

gc_sweep在总的采样占比上已经变得很少，这点从打log上面就能看出
free占比gc_sweep的时间比重增加，说明减少了遍历的时间消耗

注意点

从给table设置constant之后完整的一次gc之前，不能主动调用full gc否则会导致table子元素没有被标记，这样就会被误删除，导致访问的时候出现内存问题
table不能设置weak
table元素只能是table、string、number，不能有function，线程

结论

可以看到优化在常驻内存table大的时候很明显，主要提升了两个方面的速度：

在GCSpropagate阶段减少不必要的遍历，加快遍历速度，同时减少了新临时变量的生成
在GCSweep阶段，减少不必要的遍历，同时因为加快遍历速度，需要free的临时变量变少，所以减少了GCSweep的时间