Lua GC 垃圾回收

OStack程序员社区-中国程序员成长平台 › 门户 › 编程› LUA›LUA教程

原作者: [db:作者] 来自: [db:来源] 收藏邀请

GC原理：http://blog.csdn.net/yuanlin2008/article/details/8558103

https://blog.codingnow.com/2011/03/lua_gc_1.html

luaC_fullgc ：进行一次完整的gc

总体上分为两部分

(1)完成上次未完成GC

(2)重新开始一次完整GC。

因为在(2)中会进行完整GC，在(1)部中并不需要真正的完成GC(GC的标记消耗是很大的)只需要将节点标记为white交由(2)重新处理即可。

在(1)中跳过了标记阶段，这里没有翻转白色标记，然后交给sweep 将节点重置为white

PS：luaC_fullgc 是原子性操作

GCthreshold ：

totalbytes：通过alloc管理的内存数量

estimate：是一个内存预估值 estimate = totalbytes - udataByte PS：estimate <= totalbytes

setpause和collect 对垃圾回收的影响？？？？

标记：

对象之间的引用关系

GC的标记过程不是递归的，将这个过程拆分成几个时间片执行。

标记操作是调用reallymarkobject ，将节点转换 white ----> gray 。

因为 string 没有引用对象，但是却没有标记为black，这是一个小优化，只要不是white就不会清理，所以没必要再讲string 的颜色从gray ---> black。

userdatahe upvalue结构相对简单，所以在这里标记所引用的对象，同时将其转换为black(这里会再一次调用reallymarkobject ，但是不会产生一个深度递归，因为upvalue 不会引用另一个upvalue，所以标记操作的时间复杂度是O（1）)。打开的upvalue不会转换成black，打开的upvalue 引用了堆栈上的对象，而堆栈上的对象是易变的。标记是分段执行的，如果此时将其标记为黑色，那么栈上的值发生改变会引发问题。（？？？）

其他的结构这是把节点加入到gray list中等待后续的处理。

标记时间的复杂度O（1），保证了比较耗时的标记阶段可以分派到多个时间片中执行，而不需要长时间的等待整个标记操作的完成。

扫描阶段：

将节点转换 gray---->black ,标记引用对象。

扫描table：weak table 会在扫描的如atomic中进行清理操作，如果扫描是发现table，那么将其加入到g->weak list中，等待清理。weak table重新转换成 gray。

扫描thread：扫描节点，从gray list移除节点，加入到grayagain list，等待再次扫描。这是因为 thread 关联的对象其实是运行堆栈，堆栈是随着运行过程不断变化的。没有必要为最频繁的 stack 修改做 barrier ，那样对性能影响就很大了。最简单的办法就是把 thread 推迟到 atomic 阶段重扫描一次。这里第一次的扫描，是为了减少在atomic 扫描的时间(atomic 的扫描时间越少越好)。

扫描proto：常量、upvaluename 、子proto 、local value name。在proto的创建阶段会有大量的对象产生，很容易发生GC。

当GC阶段发生对象之间的引用变化那么就会执行 write barrier(保护)

luaC_barrierback和luaC_barrierf 区别？？？

o 引用 v

luaC_barrierf ：扫描阶段将v重新标记(V加入到当前GC)，否则将o标记为white（white并不会导致被清除，只是留到下一次gc处理）。

luaC_barrierback：将o加入到grayagain中。（这个函数只在table引用的对象发生变化调用）

table的修改很频繁，如果是用luaC_barrierf 实现，频繁改变table会导致不断有对象被加入到graylist中，可能导致扫描永远完不成。

注意，对弱表的修改是不会触发 luaC_barrierback 的。因为弱表不会是黑色。弱表也不能触发它。在扫描过程中，对弱表的修改又不会触发 barrier 。这会导致最终扫描完成后，某些弱表里可能还藏有一些新建立的强应用关系。所以atomic 节点需要再次 mark。

在lua_setmetatable中设置全局的mt，并不会触发luaC_barrierback 。所以在atomic 节点需要再次 mark g->mt

清理阶段：

字符串清理：字符串存储在开散列的hash表中，GCSsweepstring 每次清理散列表中的一列。由于清理也是分步进行的，当在字符串清理阶段发生resize散列表，有可能未清理部分的字符串会放置到以清理部分，导致字符串没办法在当前GC重置为white。待清理阶段字符串复活直接重置为white。

垃圾对象清理：存活重置为white 死亡释放空间。

UserData清理：通过GCTM 调用一个userdata 的 gc 元方法，此时调整GCthreshold 的值避免发生自动GC。

PS：string 和 upvalue 是全局唯一的，为了查找效率考虑，并没有存放在rootgc ，而是进行单独的存放。所以GC部分要对其特殊处理。

userdata处理：

userdata可能有自带的gc方法，当回收空间之前，需要调用自带的gc方法。所以userdata需要单独的处理。rootgc是头插入链表，线程是其第一个对象， userdata被放置到线程对象之后，rootgc （其他对象-->线程-->userdata）。这样就可以高效率的遍历所有userdata进行处理。在luaC_separateudata 中查找出所有有gc方法的userdata，保存到g->tmudata。然后在atomic阶段将其标记为不可清除（保证在调用自带gc方法前，对象内存不会被Lua GC回收掉）。

为什么白色标记要用两位？？？

当新建一个对象时，可能进程开始回收但未完成。这时这个对象是要等下一次回收的，如果标记为white 那么可能这次就被回收掉，如果标记为black，可能在本次回收之后不会被重置为white(回收完所有对象都要被重置为white，并且每遍历一个就重置一个)。所以这里引入两种white。

进入清理阶段之后, 将对象变为白色不会影响当前对象是否死亡的判断.

自动GC问题？？？？

当调用栈很深的情况下，可能产生大量临时对象，这是很容易发生GC，而这时候发生GC导致很多不必要的临时变量被mark。降低了GC效率。