From: SASADA Koichi <ko1@...>
Date: 2012-01-05T09:48:23+09:00
Subject: [ruby-dev:45090] Re: [ruby-trunk - Feature #5839][Open] Proposal: Bitmap Marking GC

　ささだです．

(2012/01/05 9:30), Narihiro Nakamura wrote:
> その辺りはどうなんでしょう…。実装するのはそれほど難しくないので、試し
> に実装して計測してみます。
> 
> 実装的には、sweep時に解放対象のオブジェクトに対してはobj_free()を呼ぶだ
> け、flagsは0にしない、freelistも繋がない、スロットをsweepしたあとに
> bitmapをクリアしない、オブジェクトアロケーション時にbitmapスキャン、み
> たいなのを考えています。

　個人的には，allocation のコストがどう変わるか，が気にあっていま
す．bitmap を総スキャンすると大変なので，最後のカーソルを保存する，とか
かなぁと思っていました．まぁ，導入された後で私がやってもいいですが．


>>> |　あと，nari さんが PRO で提案していた手法だと，「ビットマップ探索高速化
>>> |のため〜」云々はあまり気にしなくていいんじゃないかと思ったんですが，そう
>>> |でもないでしょうか．
>>>
>>> memalignで直接ページが得られた方が、PROの手法よりビットマップ
>>> テーブルを得るためのメモリアクセスが１段減って高速のはずです。
>>> ビットマップテーブル取得はオブジェクトごとに発生しますから効
>>> いてくるはずです。
>>
>> 　そうですね．定量的な比較がもしあると説得力が増すと思いました．
>>
> 
> 実装して比較してもよいですが、実装者の感覚としては調べるまでもな
> いような気も…。

　なるほど．自明＆大変そうなら結構です．

>> 　パッチをちらっと見ただけでの将来的な要望ですが，この辺は gc.c の中で綺
>> 麗に API（というかマクロ）で切り離せるところだと思うので，うまいこと整理
>> できるといいんでないかと思います（以前，RubyConf2011 でも喋った話ですが）．
> 
> そうですね。それはいろんなGCを選択したいなぁ、という時にやらないといけ
> ないことだと思っています。
> また、ささださんがおっしゃってる「うまいこと整理」のイメージがあまり湧
> いてないので、どういうものか例を上げてくれると想像しやすいです。

　例えば，mark 部分をマクロ化するとか，slot の allocation をマクロ化する
とか，そんな感じです．ただ，もちろんいろんな切り口のある話だと思いますの
で色々悩みどころになるんじゃないかと思います．


# ちなみに，GC を選択，というのは広範囲過ぎて危険な言葉ではないかと
# 思っています．copy gc にするのは無理だろうし．


-- 
// SASADA Koichi at atdot dot net