longlife gcパッチを作成しました

GW中にせこせこと作っていたGCパッチをruby-devに投稿しました.
内容は以下.

Railsのヒープ調査

2ヶ月ほど前に,ふと気になってRailsがどんな風にヒープを使用しているか調査してみました.
以下のグラフはscaffoldしたRailsアプリを動かした際のものです.
http://www.narihiro.info/resource/image/gc_count_statistic_from_rails.png
 
調査前は,「文字列が一番多いんじゃないか」と考えていたのですが,実際に
構文木オブジェクトがヒープの半分を占めているようです.
その構文木オブジェクトを更に詳しく調べたグラフが以下です.
http://www.narihiro.info/resource/image/gc_count_statistic_for_node_from_rails.png
 
このグラフにあるNODE_METHODやNODE_CFUNC,NODE_FBODYはメソッド定義の際に
使用され,NODE_WHILEやNODE_BLOCKはVMの内部で使用されているようです.
 

長寿命GC

更に調査をすると,これらのオブジェクトはとても長生きな事が分かりました.
そこで,これらを長寿命領域に隔離してしまおう,という改善を今回行いました.
部分的な世代別GCというイメージです.
(このアイデアの元ネタは,まつもとさんのアドバイスによるものです)
 

実装メモ

major gcを行うタイミングはヒープが拡張される時とGC.startの時にしています.
世代間の参照を記録する手法にはremembered_setを使いました.ライトバリアの
際はremembered_setに対象のオブジェクトを記録します
また,オブジェクトがremembered_set中にあることを示す為に FL_RESERVED フ
ラグを使用しています.
 

ベンチマーク

scaffoldしただけのRailsアプリでGCのプロファイルを取りました.
GC回数
改善前 : 35
改善後 : 31
 
GC時間(ms)
改善前 : 332.02
改善後 : 284.01
 
平均GC時間(ms)
改善前 : 9.48
改善後 : 9.16
 
また,Railsアプリのヒープの状態を作り出すようなベンチマークコードを書い
て,そのプロファイルも取りました.
GC回数
改善前 : 7
改善後 : 6
 
GC時間(ms)
改善前 : 1452.091
改善後 : 1208.076
 
平均GC時間(ms)
改善前 : 207.44
改善後 : 201.34

パッチ

現在の最新のrevisionへのパッチとruby1.9.1-p0へのパッチを作成しました.
gc_partial_longlife_1_9_0_p0.patch
gc_partial_longlife_r23386.patch
 

最後に

まつもとさんからこのような返信が

私が煽ったこともありますが、悪くなるケースがない or 少ないの
であれば取り込みたいと思います。いろいろなケースで試していた
だけるボランティアを募集します。私もいくつかbenchmarkの下を
試してみようと思いますが、いつ時間が取れるか分からないので。

どなたか「このコードは超遅くなるよー」とかあれば教えていただけませんでしょうか?
よろしくお願いいたします.m(_ _)m
 

追記2

まつもとさんにご指摘を頂いたので,実装メモの節を修正しました.
ライトバリアとremembered_setの認識を間違えていました.
混乱された方はごめんなさい.