这篇内容并不是上篇提到的关于弱表实现的分析。而是最近有位同学与我探讨了一些Lua的GC时，发现了两个以前从没注意过的智慧闪光点。
首先是luaC_fullgc的实现.
#define keepinvariant(g) ((g)->gcstate <= GCSatomic)
static void entersweep (lua_State *L) {
global_State *g = G(L);
g->gcstate = GCSswpallgc;
lua_assert(g->sweepgc == NULL);
g->sweepgc = sweeplist(L, &g->allgc, 1);
}
void luaC_fullgc (lua_State *L, int isemergency) {
global_State *g = G(L);
lua_assert(g->gckind == KGC_NORMAL);
if (isemergency) g->gckind = KGC_EMERGENCY; /* set flag */
if (keepinvariant(g)) { /* black objects? */
entersweep(L); /* sweep everything to turn them back to white */
}
/* finish any pending sweep phase to start a new cycle */
luaC_runtilstate(L, bitmask(GCSpause));
luaC_runtilstate(L, ~bitmask(GCSpause)); /* start new collection */
luaC_runtilstate(L, bitmask(GCScallfin)); /* run up to finalizers */
/* estimate must be correct after a full GC cycle */
lua_assert(g->GCestimate == gettotalbytes(g));
luaC_runtilstate(L, bitmask(GCSpause)); /* finish collection */
g->gckind = KGC_NORMAL;
setpause(g);
}
在luaC_fullgc中，主要的意图是首先尽可能快的结束执行到一半的GC循环，然后从头开始一轮新的GC循环，以达到fullgc的语义。
那么怎么快速结束当前未结束的循环呢，Lua采用了一个很有智慧的方法，那就是快速进入sweep阶段(即如果当前还没有处理sweep阶段，就直接进入sweep阶段)。那么我为什么说这是一个很有智慧的方式呢，这是因为不论在整个GC状态机的任意一个状态进入sweep阶段，整个GC状态都不会出错，这是我以前没有意识到的。
先来看一下整个GC状态机全部状态：
#define GCSpropagate 0 #define GCSatomic 1 #define GCSswpallgc 2 #define GCSswpfinobj 3 #define GCSswptobefnz 4 #define GCSswpend 5 #define GCScallfin 6 #define GCSpause 7
如果将一个GC循环按照标记和清除来区分，很显然GC循环的开始在GCSpropagate, 结束在GCSpause。整个GC循环被GCSatomic状态分为标记和清除两个大阶段。
为了更清楚的看清整个GC循环，我们将每个GC循环概括为GCMark和GCSweep两个阶段，并把几个GC循环连起来看。
GCMark1, GCSweep1, GCMark2, GCSweep2,GCMark3, GCSweep3…
由于atomic函数会改变当前GC循环的白色值，因此GCSweep1,和GCMakr2阶段拥有相同的白色值，而GCSweep2,GCMark3拥有相同的白色值。
从sweeplist函数可以看出GCSweep2只会清理GCSweep1和GCMark2阶段的白色对象。并把所有存活对象都变成当前GC循环的白色值。
假如我们在执行GCMark2过程中调用了luaC_fullgc导致跳过了atomic阶段的执行，那么就不会产生更换GC循环白色值的行为，这样GCSweep1,GCMark2,GCSweep2，GCMark3都使用了相同的白色值来执行标记清除逻辑。由于GCSweep1已经清除过GCSweep0和GCMark1阶段产生（包括由黑变白)的白色对象，那么GCSweep2的作用其实只剩下“把所有在GCMark2阶段标记过的对象都变白”。相当于撤销了GCMark1的作用。而从GCMark3开始就能执行一轮全新的GC循环。
这就变相达到了最快结束当前GC循环的目的。
另一个就是luaC_barrierback的实现.
#define luaC_barrierback(L,p,v) ( \
(iscollectable(v) && isblack(p) && iswhite(gcvalue(v))) ? \
luaC_barrierback_(L,p) : cast_void(0))
void luaC_barrierback_ (lua_State *L, Table *t) {
global_State *g = G(L);
lua_assert(isblack(t) && !isdead(g, t));
black2gray(t); /* make table gray (again) */
linkgclist(t, g->grayagain);
}
这个函数其实在上篇分析中也有提到过。但那是在GCMark阶段时分析的luaC_barrierback的作用。我从来没有注意过如果在GCSweep阶段，触发了luaC_barrierback会怎么样。
在GCSweep阶段会触发luaC_barrierback么？答案是肯定的。因为sweeplist是增量执行的，不可能一下子就把所有黑对象变白。如果这时操作黑对象，就会触发luaC_barrierback。
那么在GCSweep阶段，如果触发了luaCbarrierback，那么相关黑对象会被变成灰对象，然后被挂在g->grayagain链表上。同时如果一个对象触发了luaC_barrierback， 说明他还没有对sweeplist处理过，也就是说最终他一定会被sweeplist函数变成白色。
这时就会存在一种情况，一个对象被挂在g->grayagain链表上，但是它是白色。这就是其中的智慧闪光点，虽然一个白色对象挂在g->grayagain, 但是他不会有副作用。因为在restartcollection函数中的 g->gray = g->grayagain = NULL语句会将整个grayagain链表清空。同时虽然白色对象的gclist字段依然有无效值，但是在下次插入gray或grayagain之前，会对此对象的gclist字段重新赋值，因此也不会有任何副作用。
纵观这两个例子可以发现，sweeplist本来是为了GCSatomic阶段之后清除对象而生，而luaC_barrierback本来也是为了在GCMark阶段保持GC循环不变式而生。但是他们在这两个场景之外，依然有良好的适用场景。这得益于良好的抽象，我有时甚至都在想，这也许已经是人类智慧的极限了。