ruby 2.0 bitmap marking 節省的多個 proccess 共用記憶體空間

閱讀 ruby 2.0 garbage collection

http://patshaughnessy.net/2012/3/23/why-you-should-be-excited-about-garbage-collection-in-ruby-2-0

原本的 ruby GC 演算法 mark and sweep:
Ruby 的 String 等物件在 ruby 記憶體配置中，都是由一組 flag/RValue 的雙欄位物件組成，RValue 儲存在 heap 中，當新申請的物件找不到足夠記憶體時，就會啓動 garbage collection(GC), GC 演算法就是去找到哪些 RValue 已經沒人在用可以重新釋放，讓新的物件使用，flag 中有個欄位稱為 FL_MARK，設定 FL_MARK 為 1 表示正在使用中，當整個 heap 檢查完，沒有 mark 的 RValue 就會加入一個 free list，被 sweep (清除)，每當使用新的物件或數值就會使用 free list 中的 RValue，當 free list 又被用空後，就會再次執行 mark and sweep 的 GC 產生新的 free list，如此進入新的循環。

如果執行完 mark and sweep 後發現沒有多餘 RValue 可供生成 free list (空的 free list) 該怎麼辦? ruby interpreter 就會產生新的(一次十個) heap 並產生相對應的新 free list 給新物件使用。

Ruby 2.0 嘗鮮版 bitmap marking(號稱比 rubyEE 更快的 GC):使用 copy on write optimization 的 GC 可以讓不同的 heap arrays 共用有相同值的 RValue 物件，也就是多個 process(比如 ruby on rails 有許多共同的網頁物件)，但可惜的是再 mark and sweep 演算法中，會把這些共用物件設定為 marked，因此無法繼續享受共用 RValue 來節省記憶體空間。但Phusion Passenger 的 Hongli Lai 已經在 ruby EE中改掉這個 marked as modified object 的問題。而現在 Narihiro Nakamura 的 bitmap marking 修改是放棄 flag/RValue 的資料結構，改在每個 heap header 採用 bitmap 紀錄記憶體是否已使用，因此 mark 的動作，不會再去改到 heap 本身的資料結構，享受到 copy on write optimization 來節省共用物件的記憶體空間了。

另外一個修改是這些 heap header 必須對齊到 2 的次方位置 (posix_memalign, not malloc)，優點是計算 heap header 位址的方式較方便

在 heroku 的 ruby on rails 可以在 Gemfile 加上:
ruby "2.0.0"
指定 ruby 版本