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

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

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

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