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

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

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

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