From: Narihiro Nakamura Date: 2012-01-05T12:30:31+09:00 Subject: [ruby-dev:45092] Re: [ruby-trunk - Feature #5839][Open] Proposal: Bitmap Marking GC nari です。 2012年1月5日9:48 SASADA Koichi : > 　ささだです． > > (2012/01/05 9:30), Narihiro Nakamura wrote: >> その辺りはどうなんでしょう…。実装するのはそれほど難しくないので、試し >> に実装して計測してみます。 >> >> 実装的には、sweep時に解放対象のオブジェクトに対してはobj_free()を呼ぶだ >> け、flagsは0にしない、freelistも繋がない、スロットをsweepしたあとに >> bitmapをクリアしない、オブジェクトアロケーション時にbitmapスキャン、み >> たいなのを考えています。 > > 　個人的には，allocation のコストがどう変わるか，が気にあっていま > す．bitmap を総スキャンすると大変なので，最後のカーソルを保存する，とか > かなぁと思っていました．まぁ，導入された後で私がやってもいいですが． > では、おまかせします :) >>>> |# あと，REE との性能比較があると興味深いと思ったけど， >>>> |# いろいろ難しいかな． >>>> >>>> うーん、1.8と1.9の差の方が大きすぎて意味のある性能比較はムリ >>>> でしょう。メモリ消費量比較くらいなら有意義な比較ができるかな。 >>> >>>　 はい，難しいと思います．が，何らかの指標があると，マーケティングには良 >>> さそうです． >> >>REEとメモリ消費量を比較したのがあったほうがいいかもしれませんね。 >>passengerは面倒そうなので、まずはskkzipcodeを動かしてみます。 REEとRuby2.0ビットマーキングのメモリ使用量を比較しました。 https://gist.github.com/1542547#file_skkzipcode_mem_usage.txt Ruby2.0はREEよりも省メモリなので、総メモリ使用量が変動していますが、 共有メモリ使用量と私有メモリ使用量の割合はほとんど変わりないようです。 >>>　 パッチをちらっと見ただけでの将来的な要望ですが，この辺は gc.c の中で綺 >>> 麗に API（というかマクロ）で切り離せるところだと思うので，うまいこと整理 >>> できるといいんでないかと思います（以前，RubyConf2011 でも喋った話ですが）． >> >> そうですね。それはいろんなGCを選択したいなぁ、という時にやらないといけ >> ないことだと思っています。 >> また、ささださんがおっしゃってる「うまいこと整理」のイメージがあまり湧 >> いてないので、どういうものか例を上げてくれると想像しやすいです。 > > 　例えば，mark 部分をマクロ化するとか，slot の allocation をマクロ化する > とか，そんな感じです．ただ，もちろんいろんな切り口のある話だと思いますの > で色々悩みどころになるんじゃないかと思います． > > > # ちなみに，GC を選択，というのは広範囲過ぎて危険な言葉ではないかと > # 思っています．copy gc にするのは無理だろうし． 理解力不足で申し訳ないのですが、何か具体的な目的はあるんでしょうか？ アロケーションの戦略を変えたり、マーキングの方法を変えたり、を簡単にし たいとかそういう話でしょうか？ 例えば並列マーキングに簡単に切り替えられ るとか、tcmallocが簡単に使えるようになるとか…。 個人的には具体的な目的があったほうがAPIも定義しやすいと思っています。 -- Narihiro Nakamura (nari)