終于可以看看這個gc庫是如何收集垃圾內存的了。還是老方法，先貼代碼，來一個直觀上的認識
1
void
2gc_collect()
3
{
4
int i;
5 stack_pack();
6 cache_flush();
7 gc_mark(0);
8
for (i=0;i<E.size;i++) {}
9 E.mark+=2;
10
}
首先是
stack_pack，這將是要研究的第一個子函數。根據其名字，可以推測會操作前面看過的管理自由內存的堆棧，事實上也是如此。該函數將清理堆棧，將暫時不能釋放的自由內存用一種自動化的方式標記出來，這種方式就是為他們建立依賴關系。建立依賴關系也是內存不能被當作垃圾的唯一理由。
下一步是
cache_flush，這個以前已經看過，將cache的依賴關系寫入到實際管理的容器上。
第三步是
gc_mark，用來給所有有依賴關系的內存做一下標記，證明他們不是垃圾。
第四步是一個for循環，循環體太長暫時先不貼出來，不過其工作就是將標記不合格的內存釋放，因為他們是垃圾內存。
最后更新標記，標記是一個遞增的整數。
垃圾收集的過程直觀上就是這樣，現在就來逐步細看，先看看stack_pack。聲明一點，通過這個函數，可以解開之前在gc_leave中為何會有E.bottom大于 E.current的緣故（除了初始化）。
1static void
2stack_pack()
3{
4 int bottom=stack_pack_internal(E.stack.bottom,E.stack.current,E.stack.top);
5 E.stack.top=E.stack.bottom=bottom;
6 E.stack.current=bottom-1;
7}
stack_pack的代碼很少，因此可以斷定關鍵的地方都在
stack_pack_internal上了，其返回值bottom也有重要意義。
第5、6行，直接將top,bottom,current指針重置到一個類似于初始化的狀態，不過此時的bottom通常都已經往上移動了，而current小于bottom。
也就是說，每次調用gc_collect后，總會造成current小于bottom的結果，那么gc_leave的實現里有對這種判斷的處理也就不奇怪了，不過具體這種處理是何用意，看了stack_pack_internal之后再說。
1static int
2stack_pack_internal(int from,int to,int top)
3{
4 if (to < from) {
5 int parent = E.stack.data[to].stack;
6 while (from < top) {
7 node_add(parent,E.stack.data[from].handle);
8 ++from;
9
}
10 return to+1;
11 }
12 else {
13 int bottom=stack_pack_internal(from,to-E.stack.data[to].number,to);
14 int node=node_alloc(0);
15 ++to;
16 while (to<top) {
17 node_add(node,E.stack.data[to].handle);
18 ++to;
19 }
20 node_add(E.stack.data[bottom-1].stack,node);
21 E.stack.data[bottom].stack=node;
22 return bottom+1;
23 }
24}
快速掃一眼stack_pack_internal，發現他是一個遞歸函數，其次確認一下三個參數，分別對應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，或者是從這個減法。沒錯喲，這三個用于遞歸的參數，其實是在父函數環境下的堆棧指針位置。也就是說，stack_pack_internal遞歸的調用，由于執行常規的else部分的代碼，因此不斷的傳遞父函數的堆棧指針位置，不斷的尋根，不斷的追宗認祖，最終就會回到stack剛初始化的狀態，此時 current < bottom。很酷的，現在不得不暫時放下else部分，來看看if部分，這if部分可就只是為了這么一下而準備的。
第5行，取的是current節點處的值。剛初始化的stack，這里存放著全局內存之根，最大的所有者。
接下來，由于此時bottom 等于 top，所以while循環暫不執行，直接返回bottom。現在可以回到else部分了。
第14行，從 E.pool中分配了一個節點，當然該節點實際沒有維護任何內存，不過這個節點可有大用處。
第16到第19行，這個while循環內，將某一級函數（遞歸太多，是哪一級已經不重要了）中分配出來的自由內存和剛申請的node建立依賴關系，這級函數的自由內存id可都記錄在current+1到top之間的handler中呢（current記錄父函數分配的自由內存數量）。
第20行，將剛申請node和 E.stack.data[ bottom -1 ].stack建立以來關系，不過這到底是什么呢？如果bottom-1等于0的話，那就是node和全局建立依賴關系，否則，看起來就像是和父函數建立了依賴關系。第21行驗證了這個想法，這一賦值，將node記錄到了堆棧中。就此也知道了stack成員變量的作用，表示某個函數的節點。
最后返回bottom+1，即bottom指針移動了，而bottom-1必然指向了代表父函數的node。
以上的分析看其來都比較混亂，不過從整體想像的話：
假設函數其實是一種對象，他引用著那些在他函數體內分配出來的自由內存，因此他和那些內存就有依賴關系。從最上層的函數開始，建立表示該函數對象的節點，和所有在這一級函數中分配的自由內存建立依賴關系。然后到下一級子函數，也建立一個表示該函數對象的節點，和所有在這一級函數中分配的自由內存建立依賴關系。如此遞歸，直到調用了gc_collect的這一級函數為止。
管理自由內存的堆棧，經過這樣處理后，里面就剩下了每一級函數對象的節點id，一個個的緊挨著。而作為到調用gc_collect為止，這一路下來分配的自由內存，都是暫時不能釋放的，已經建立依賴關系放進了 E.cache。
根據stack_pack后兩行的代碼，就可以判斷出if代碼中while循環是用來干什么吃的了：同一級函數中，在gc_collect后，繼續分配自由內存，然后再gc_collect的話，就會執行到該while循環，本質也是用來建立依賴關系的。
最后說說看
gc_leave時無法理解的代碼吧，現在已是真相大白了
1 else {
2 int parent,child;
3 --E.stack.bottom;
4 parent=E.stack.data[E.stack.bottom-1].stack;
5 child=E.stack.data[E.stack.bottom].stack;
6 node_add(parent, child | UNSET_MASK);
7 node_free(child);
8 E.stack.current=E.stack.bottom-1;
9 E.stack.top = E.stack.current + 1;
10 }
這是current小于bottom的情形，已經被gc_collect了，此時 E.stack.data[0]到 bottom指針之間應該都是每一級函數的象征節點。
第4、5行，就是一個父函數和子函數的關系，現在既然已經從子函數中退出了，那么也是時候解放子函數中分配的自由內存的時候了，因此第6行解開了父子函數的依賴關系，那子函數中分配的自由內存也相應的變成垃圾了。
最后兩行恢復父函數的堆棧，我想堆棧的形狀也差不多了，E.stack.data[0]到 bottom指針之間應該都是每一級函數的象征節點。
posted on 2008-09-21 23:17
LOGOS 閱讀(1679)
評論(3) 編輯 收藏 引用