終于可以看看這個gc庫是如何收集垃圾內存的了。還是老方法，先貼代碼，來一個直觀上的認識

首先是stack_pack，這將是要研究的第一個子函數。根據其名字，可以推測會操作前面看過的管理自由內存的堆棧，事實上也是如此。該函數將清理堆棧，將暫時不能釋放的自由內存用一種自動化的方式標記出來，這種方式就是為他們建立依賴關系。建立依賴關系也是內存不能被當作垃圾的唯一理由。
下一步是cache_flush，這個以前已經看過，將cache的依賴關系寫入到實際管理的容器上。
第三步是gc_mark，用來給所有有依賴關系的內存做一下標記，證明他們不是垃圾。
第四步是一個for循環(huán)，循環(huán)體太長暫時先不貼出來，不過其工作就是將標記不合格的內存釋放，因為他們是垃圾內存。
最后更新標記，標記是一個遞增的整數。

垃圾收集的過程直觀上就是這樣，現在就來逐步細看，先看看stack_pack。聲明一點，通過這個函數，可以解開之前在gc_leave中為何會有E.bottom大于 E.current的緣故（除了初始化）。
stack_pack的代碼很少，因此可以斷定關鍵的地方都在stack_pack_internal上了，其返回值bottom也有重要意義。
第5、6行，直接將top,bottom,current指針重置到一個類似于初始化的狀態(tài)，不過此時的bottom通常都已經往上移動了，而current小于bottom。
也就是說，每次調用gc_collect后，總會造成current小于bottom的結果，那么gc_leave的實現里有對這種判斷的處理也就不奇怪了，不過具體這種處理是何用意，看了stack_pack_internal之后再說。

快速掃一眼stack_pack_internal，發(fā)現他是一個遞歸函數，其次確認一下三個參數，分別對應bottom，current，top，也就是當前函數下的堆棧指針位置。
第4行的代碼可以看成 if ( current < bottom )，通過以前看過的代碼，可以了解到以下3點：
1.初始化之后，current < bottom
2.調用gc_collect之后，current < bottom
3.調用了gc_enter后，current 絕對不會小于bottom
因此else部分的代碼才是要先考慮的代碼，也就是遞歸的部分。

第13行的代碼可以寫成
bottom = stack_pack_internal( bottom , current - E.stack.data[ current ].number , current )
有看出什么來嗎？比如說從number，或者是從這個減法。沒錯喲，這三個用于遞歸的參數，其實是在父函數環(huán)境下的堆棧指針位置。也就是說，stack_pack_internal遞歸的調用，由于執(zhí)行常規(guī)的else部分的代碼，因此不斷的傳遞父函數的堆棧指針位置，不斷的尋根，不斷的追宗認祖，最終就會回到stack剛初始化的狀態(tài)，此時 current < bottom。很酷的，現在不得不暫時放下else部分，來看看if部分，這if部分可就只是為了這么一下而準備的。
第5行，取的是current節(jié)點處的值。剛初始化的stack，這里存放著全局內存之根，最大的所有者。
接下來，由于此時bottom 等于 top，所以while循環(huán)暫不執(zhí)行，直接返回bottom。現在可以回到else部分了。

第14行，從 E.pool中分配了一個節(jié)點，當然該節(jié)點實際沒有維護任何內存，不過這個節(jié)點可有大用處。
第16到第19行，這個while循環(huán)內，將某一級函數（遞歸太多，是哪一級已經不重要了）中分配出來的自由內存和剛申請的node建立依賴關系，這級函數的自由內存id可都記錄在current+1到top之間的handler中呢（current記錄父函數分配的自由內存數量）。
第20行，將剛申請node和 E.stack.data[ bottom -1 ].stack建立以來關系，不過這到底是什么呢？如果bottom-1等于0的話，那就是node和全局建立依賴關系，否則，看起來就像是和父函數建立了依賴關系。第21行驗證了這個想法，這一賦值，將node記錄到了堆棧中。就此也知道了stack成員變量的作用，表示某個函數的節(jié)點。
最后返回bottom+1，即bottom指針移動了，而bottom-1必然指向了代表父函數的node。

以上的分析看其來都比較混亂，不過從整體想像的話：
假設函數其實是一種對象，他引用著那些在他函數體內分配出來的自由內存，因此他和那些內存就有依賴關系。從最上層的函數開始，建立表示該函數對象的節(jié)點，和所有在這一級函數中分配的自由內存建立依賴關系。然后到下一級子函數，也建立一個表示該函數對象的節(jié)點，和所有在這一級函數中分配的自由內存建立依賴關系。如此遞歸，直到調用了gc_collect的這一級函數為止。
管理自由內存的堆棧，經過這樣處理后，里面就剩下了每一級函數對象的節(jié)點id，一個個的緊挨著。而作為到調用gc_collect為止，這一路下來分配的自由內存，都是暫時不能釋放的，已經建立依賴關系放進了 E.cache。

根據stack_pack后兩行的代碼，就可以判斷出if代碼中while循環(huán)是用來干什么吃的了：同一級函數中，在gc_collect后，繼續(xù)分配自由內存，然后再gc_collect的話，就會執(zhí)行到該while循環(huán)，本質也是用來建立依賴關系的。

最后說說看gc_leave時無法理解的代碼吧，現在已是真相大白了
這是current小于bottom的情形，已經被gc_collect了，此時 E.stack.data[0]到 bottom指針之間應該都是每一級函數的象征節(jié)點。
第4、5行，就是一個父函數和子函數的關系，現在既然已經從子函數中退出了，那么也是時候解放子函數中分配的自由內存的時候了，因此第6行解開了父子函數的依賴關系，那子函數中分配的自由內存也相應的變成垃圾了。
最后兩行恢復父函數的堆棧，我想堆棧的形狀也差不多了，E.stack.data[0]到 bottom指針之間應該都是每一級函數的象征節(jié)點。