第三章 Garbage Collection 設計
3.6 Garbage Collection 運作和對 JAIP 修改
前面的章節都是在著重在每個元件單一的介紹，有了前面的認知，接下來會 說明我們所設計 GC 的整體運作過程。
一開始收到分配空間的需求，就會到 GC table 中找有沒有回收空間可以利用，
如下圖所示，0 代表可以在重複利用此空間，1 代表此空間能被其它 process 所佔 領，每個欄位都會標記所佔用的 size 多大，比如說，下圖第一欄就是 50 個 word，
各個 GC 表格中每個欄位都會對應的 DDR2 的 heap memory 的實體位址。查詢完 table 就完成創建物件的動作。
Figure 16. 分配物件時 GC table 的狀況
當每次完成分配空間，另一方面在同時執行的就是回收物件的控制器，只要 判斷出這是在一個可以回收的 method 內所產生的物件就會紀錄此物件在另外一
GC table S 50(word) 1
S 100 1
S 10 1
S 70 0
S 90 0
… ..
… ..
S 30 1
.. ..
Heap Memory
23
張表格中，等 method 返回即可立刻回收，如果不可回收就不會有記錄，不可回收 的就是返回還會用到此物件的。以下將用流程圖完整呈現整體設計的概念，包括 分配、回收的情況都會一起討論。
下圖的 Heap Allocation request，就是收到別的元件傳來的創立物件的要求，
之後 Garbage Collection Unit 會做出相對應的動作然後到了完成時，就會給出ㄧ個 位址告訴元件，這個物件可以在 Heap 上做使用，所有的物件控管都是經由 Garbage Collection Unit，除了在本節最後所述的 RISC core，不會經過此 Unit，其餘都會。
Figure 17. 分配物件的流程圖
收到 Request 後會先去檢查 GC table 是否有可用的回收空間可以用，如果沒 有的話就直接出ㄧ個新的位址使用，這個位址就是目前 Heap 使用到哪裡的位址，
如果有找到回收空間可以用，也就代表所需大小大於此找到的回收空間，就可以 使用此空間，使用後也要在更新 GC table 中的欄位，從原本的可回收使用，標示 成有物件使用中，避免讓其他物件誤以為此空間還可以使用，這樣就會造成錯誤，
Heap Allocation
request Look up GC table
Available Space?
Use it and update table
Finish no
yes Allocate new
Heap space
24 的動作即物件生成，我們就要把此 reference 推到堆疊上，記綠此物件是在此 method 裡面生成的，當遇到這個 method 返回時這些物件就要一併被回收，因為
Local method enter
Push reference onto stack
form stack Is method flag?
Start collection through reference YES
NO YES
25
在收集的過程，因為會有很多 return 的 bytecode 會出現，因此我們要如何判 斷這個 return 是屬於某個的 invoke method 的 bytecode 也是值得討論的地方，在這 邊的做法是，我們會設計ㄧ個累加器，當收到 invoke method 會加ㄧ，收到 return 會減ㄧ，當進入ㄧ個 method 開始收集的時候就必須記錄此累加器的值，因為進入 method 過程中也會有很多 invoke method 的 bytecode 和 return 的 bytecode，我們 就可以藉由此累加器，判斷這個 return 的 bytecode 就是屬於當初我們引發收集的 bytecode，也就是收到 return 時而且當初記錄的值就是等於現在累加器的值，就是 代表結束此次的收集。
由以上的運作我們可以知道，每當要創建物件就必須要等待一些 cycle 因此 在之前的設計不用等待即可直接再 Heap 找到空間分配給此物件，因此我們在原 先的設計上必須修改，再 Dynamic Resolution，準備要進入 Heap allocation 狀態 時，必須多加入ㄧ個狀態，就是 wait for garbage collection state，意義再於等待 garbage collection 回傳位址，回傳之後才可以進行後續的動作，另ㄧ個需要修改 的地方是再創立陣列的物件，再創立陣列物件有其他的 FSM，因此我們也需要修 改，作法如同上述所講，也是新增ㄧ個狀態，去等 garbage collection controller 回 傳位址之後，才可以進行後續的動作，其餘的狀態皆無改變。
26
Figure 19. 修改後的 AASM
上圖就是多新增ㄧ個狀態 wrArr2Hp 另外剛所提到的 Dynamic Resolution 中要 進入 Heap Allocation 時也是如上圖所示一樣的修改，因為所花的 cycle 長短不一，
會有像迴圈ㄧ樣等待 completion 信號線才會進入到 wrIDReq 的狀態。每個狀態的 意義就如命名ㄧ般，wr 就代表 write，WrLenReq 就是會先發送寫長度的請求，在 來才會進入到下個 state 因此 wrLen 就代表要寫此次陣列的長度到 Heap 中。
還有另外ㄧ個修改是去停住整個 JAIP 的運作也就是，stall all 的信號線，由 上述的加入另外ㄧ個狀態，就是要來等待 garbage collection controller 回傳位址，
此時就也必須傳入ㄧ個信號告訴 JAIP 說現在整個系統也要停住，這樣才可以正確 的執行。
normal wrArr2Hp
wrLenReq
wrIDReq
wrID
GC_cmplt =1 Newarr = 1
wrLen
Runable_cmplt =1 Runable_cmplt =1
27
Figure 20. Garbage Collection 處理 RISC 方式
在上圖中，因為我們有兩個核心，除了 JAIP 外另外ㄧ個是 RISC core，
但是我們實作主要再硬體實作，因此軟體部份我們沒有處理，也就是 RISC core 發送 request 要分配 Heap 空間時，Garbage Collection Unit 就直接給予目前 Heap 使用到哪裡的位址，所以我們只會分配 Current Heap pointer 給它，讓 RISC core 繼續寫下去，不會給予我們搜尋到可回收的空間使用，因為沒有做任何處理，我 們也不知道此給予的區塊甚麼時候可以回收，我們會這麼做的原因是，我們開發 此 JAIP 最終目的要全部的硬體化，所以日後在 RISC 將不會有要求 Heap 空間的 需求。當 JAIP 要求 Heap Allocation Unit 分配空間我們就會處理，因此還會多拉 ㄧ個信號，也就是 Address，表示這是目前搜尋到可以重複使用的空間。和 RISC 溝通時我們採用 memory map register 的方式，透過寫 register 的值，這些值就會 傳送到 BUS 上，而 RISC 就會知道哪些值是屬於它所要接收，就可以達溝通的目 的，實作上我們是採用 BRAM，這些 BRAM 的值是可以和 RISC 所互通的，在使 用 xilinx 工具創建 IP 時，可以勾選是否要使用此 BRAM。
Garbage Collection Unit
Current Heap pointer Address
Memory map interface
RISC core
Heap Allocation Unit
Request
Request
28