mark改善案おひさしぶり。mark時間を短縮するアイディアはないか、考えている。barrierを導入しないというものがある。前にTwitterで、「いくつかのオブジェクトをまとめて、その単位でマークする」というアイディアを披露してみたが、すぐに三浦さんから「トラバースのコストが減らないから効果ないんじゃない」との指摘が。考えてみたら、確かにその通り。50年間、いろんな人が考えてきたGCで、画期的なアイディアを思いつくのは難しいよね。いう「誰も知らない系」ではなくて、mark時間短縮に効果のありそうなアイディアは、私の思いつく限り3つ。ひとつはビットマップマーキング。markをオブジェクトヘッダ内ではなく、外に用意したビットマップに置く。マークチェックにメモリ中オブジェクトにアクセスしなくて済むこと、それによりワーキングセットが小さくなることと、仮想記憶のページを汚さないことがメリット。markフェーズの並列化。markは相互依存が少ないので、マルチコアマシンでは効果的。ビットマップ操作はアトミックではないので前日のビットマップマーキングとは相性が悪い。ビットマップのチェックや更新のたびにロックをかけてちゃコストが高すぎる。ビットマップじゃなくて、1オブジェクトあたり1バイト使う、バイトマップにすることでロックは回避可能だと思う(だよね)。バイトマップにするとメモリ消費量が8倍になっちゃうけど、この領域は他の最適化に使えるかも。mark対象のオブジェクトそのものを減らしちゃうこと。ノードやメソッド、組み込みクラスなどをmark対象から外しちゃう。あとはオブジェクトのimmediate化。ある意味、もっとも正統的なアプローチ。1.9.2ではだいぶ外したから、後は組み込みクラスかな。組み込みクラスを別扱いすると、ユーザー定義クラスだけ一気に消去のようなことが可能になって、mod_rubyのようなタイプがうれしいかも。あと、MVMで組み込みクラスを共有できて、初期化コストが下がるとか。これらを直接書き換えないようにしないといけないけど、それは隠しクラスで実現できそう。