luaC_barrierback和luaC_barrierf 區別
在GC過程中對新建的對象引用關係進行處理。
例如：o 引用 v
luaC_barrierf ： 掃描階段將v重新標記(V加入到當前GC)，否則將o標記爲white
luaC_barrierback：將o加入到grayagain中。grayagain在原子操作中進行處理
luaC_barrierback用於監控table的key和value 變化。因爲table是易變的，如果使用luaC_barrierf ，那麼每次改變key或value都重新掃描新對象，導致標記時間的增長。
所以使用luaC_barrierback當發生改變時，見其加入grayagain中，這就將table分爲了兩種，一種是未改變，一種是改變的，再次發生改變時也不會重複加入到grayagain中。
等待amotic階段重新掃描真個table表
String：
字符串存儲在開散列的hash表中，GCSsweepstring 每次清理散列表中的一列。由於清理也是分步進行的，當在字符串清理階段發生resize散列表，有可能未清理部分的字符串會放置到以清理部分，
導致字符串沒辦法在當前GC重置爲white。
table：
weak table 只有在所有對象mart完才能確定哪些節點需要釋放，所以weak table 一直爲gray（引用對象未遍歷）,所以對weak table的修改不會觸發 barrier（只有black的節點纔會觸發barrier）。
所以在mart 階段結束後，table中可能還會存在一些強引用。所以在atomic 階段對weak table 進行remart，所有的weak table在 mart階段都被放入到g->weak鏈表中。
線程：
線程引用的是線程堆棧，在運行時整個堆棧都是一直變化的，如果加入luaC_barrier監控變化，會導致運行效率降低，所以Lua默認線程就是一直在變的，在mart是不會標記爲black，而是像處理table一樣在amotic階段重新掃描。
upvalue：
新建的upvalue（打開狀態）存儲在g->uvhead和L->openupval中，不連接在alloc鏈表上。當close upvalue時將upvalue放回到alloc中並從openupvalue和uvhead中移除。所以處理GC處理upvalue時，如果是close upvalue 則像普通對象一樣處理。open upvalue則需要特殊處理。openupvalue 只有可能被線程和lua closure引用，而只被線程引用而沒被lua closure引用的upvalue 是無意義的，應該被清除掉。所以線程對upvalue是弱引用。當mart階段只會將open upvalue 從white 變爲 gray，用於標記是否被lua closure引用。在清理階段，線程對象遍歷自己的upvalue ，清理掉沒有被引用到的upvalue。當線程退出時也會清理open upvalue。open upvalue 由於引用棧上的值，變化頻繁，所以也需要在atomic階段重新remart。
userdata處理：
由於userdata由_gc元方法存在，清理之前應該調用_gc元方法。所以需要遍歷所有的userdata，Lua將userdata存儲在alloc鏈表中，但是區別於其他對象頭插入到alloc中，userdata插入到線程對象之後，其他對象-->線程-->userdata。在atomic階段 通過luaC_separateudata 查找所有已經"dead"，並將帶_gc 方法的userdata，將其從alloc鏈表中移除，加入到tmudata雙向鏈表中，並標記FINALIZEDBIT，防止_gc元方法重複調用。在GCSfinalize階段遍歷tmudata，調用_gc元方法並將其從tmudata中移除，重新加入到alloc鏈表中。dead的userdata並不在本次gc中回收，而是先做標記然後調用_gc元方法，然後在下一次的GC中回收。
base type metatable:
基本類型的元表是共享的，而不是像table 等 是每個對象獨享的。所以 base type metatable 存儲在 g->mt中（也在alloc中）。當設置元表時，table 等會觸發barrier，但是base type metatable 由於存儲結構關係，barrier無法處理，所以並不會觸發barrier。所以在atomic階段會重新remart base type metatable(mart 過程中引用關係的改變)。