繼stack_pack將堆棧中的內(nèi)存和所分配的函數(shù)之間建立依賴關(guān)系之后，就到了對(duì) E.pool中所有管理的內(nèi)存進(jìn)行標(biāo)記的時(shí)候了。

由于暫時(shí)還不想考慮weak table的內(nèi)容，我暫時(shí)將這一部分的代碼去掉。
來(lái)看看是如何對(duì)內(nèi)存隊(duì)列進(jìn)行標(biāo)記的。首先，形參root是依賴關(guān)系的父節(jié)點(diǎn)，是 E.pool數(shù)組中的索引。在gc_collect中 root = 0，表示從全局根節(jié)點(diǎn)開始，更準(zhǔn)確的說(shuō)從main函數(shù)對(duì)象開始，遍歷整個(gè)依賴關(guān)系構(gòu)成的樹，對(duì)每一個(gè)節(jié)點(diǎn)進(jìn)行標(biāo)記。
第4行，是對(duì)節(jié)點(diǎn)是否已經(jīng)被標(biāo)記的判斷。第6行對(duì)該節(jié)點(diǎn)進(jìn)行標(biāo)記。第10、11行則對(duì)該節(jié)點(diǎn)所引用的子節(jié)點(diǎn)重復(fù)這一標(biāo)記過(guò)程。
整個(gè)依賴關(guān)系是樹狀的，利用先序遍歷標(biāo)記所有還被引用的內(nèi)存節(jié)點(diǎn)。這就是gc_mark所作的工作。

最后，是對(duì)所有沒(méi)有標(biāo)記過(guò)的內(nèi)存進(jìn)行回收。
用for循環(huán)遍歷 E.pool，所有分配的內(nèi)存，因?yàn)楸粯?biāo)記的內(nèi)存的值是 E.mark + 1，所以只要 E.pool[i].mark <= E.mark的，都算是垃圾內(nèi)存了，因此for循環(huán)里面的兩個(gè) if 和 else if在垃圾內(nèi)存的角度上并沒(méi)有差別，都是被回收的內(nèi)容，但是這兩個(gè)代碼塊多少還是有差異的，因此稍微想了一下。
首先，從之前做標(biāo)記的代碼看，沒(méi)有被標(biāo)記過(guò)的內(nèi)存應(yīng)該是小于 E.mark的，因此if代碼塊是理解上的正常流程。而else if 部分，檢測(cè)內(nèi)存的標(biāo)記等于 E.mark，這個(gè)怎么看都是沒(méi)有可能的，因?yàn)闃?biāo)記值是 E.mark+1，而E.mark以+2遞增。這有可能是其他一些我還沒(méi)看過(guò)的代碼，對(duì)節(jié)點(diǎn)進(jìn)行了標(biāo)記也說(shuō)不定，畢竟還有一個(gè)weak_table沒(méi)有接觸呢。
此外還有一個(gè)細(xì)節(jié)，else if部分，沒(méi)有調(diào)用node_free(i)，釋放了內(nèi)存，但是節(jié)點(diǎn)保留著，這讓我更確認(rèn)這是一塊還沒(méi)有開辟的代碼區(qū)域造成的，不過(guò)，這還是等以后看到相關(guān)內(nèi)容的時(shí)候，再來(lái)考證這里的內(nèi)容吧。

最后，來(lái)看看gc_link中解除依賴關(guān)系的代碼，現(xiàn)在已經(jīng)對(duì)整個(gè)gc庫(kù)有了整體的認(rèn)識(shí)，這部分代碼也就不在話下了
第3行，將被解除關(guān)系的內(nèi)存id壓入堆棧，看起來(lái)目的是讓這塊內(nèi)存再稍微活長(zhǎng)久一點(diǎn)，至少要活到離開當(dāng)前函數(shù)后。
然后第4行，解除了之前主動(dòng)添加的依賴關(guān)系，在cache_flush的時(shí)候，將會(huì)從children數(shù)組中刪除prev_id。