继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。