tech-sjh

2013年2月18日 星期一

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 版本

沒有留言:

張貼留言

版權宣告、免責聲明


姓名標示、非商業性、相同方式分享3.0台灣授權條款授權。
免責聲明: 本文所載資料僅供參考,並不構成投資建議,
讀者閱讀或使用該資料所導致結果需要自擔風險與責任,
作者概不承擔閱讀人行為之任何風險與責任。
除非有特別宣稱,作者言論並不代表所屬任何團體、公司、或其他人意見。