Ruby 1.9.3 Preview 1 がリリースされ、APIに追加があったが、GCのアップデート、lazy sweep GC（遅延開放GC）が含まれた。
InfoQは Ruby 1.9.3に lazy sweep GCの変更をコントリビュートした Narihiro Nakamura 氏に話を聞いた。
InfoQ: lazy sweep GC はこれまでのGCとどう違うのですか？
Simple（非遅延） Mark Sweep GCは、マーク付けと開放を自動的に実行します。また全ヒープを開放し、生きている全オブジェクトを freelistにリンクします。
Lazy sweepでは、適当なマークのないオブジェクトを見つけて、オブジェクトの割り当てが開始したらヒープを開放します。
InfoQ: ところで、lazy sweep GCの一番の利点は、停止時間が短いことですよね？ すなわち、停止時間は、続行するのに充分なフリースペースを見つける時間に限られるのですよね？
そうです。Lazy sweepはGCのレスポンス時間の改善します。すなわり、最悪ケースの時間が短くなります。しかし、GCの全体的なスループットは落ちます。
私は、 Simple M&S GC と Lazy sweep GCをMRIで、ベンチマークプログラム (http://redmine.ruby-lang.org/attachments/959/bm_gc_fragmentation.rb)を使って比べました。
最大 GC 時間：48.00ms => 28.00ms (58%)
全 GC 時間：0.83ms => 0.92ms (110%)
InfoQ: lazy sweep GCが不利になるのは、どのようなタイプのプログラムの動きなのでしょうか？
もしプログラムが多くの長寿命なオブジェクトを生成すれば、 lazy sweepは、マークのないオブジェクトを見つけ出せないでしょう。その場合、 lazy sweepは、１つのオブジェクトをアロケートするのに長い時間かかります。私は、ほとんどの場合、lazy sweepのパフォーマンスの方が、依然として M&S GCよりもいい、と考えています。
InfoQ: 今後のMRI 1.9.xに向けたGCの開発、あるいは改善のための計画が何か、ありますか？
ええ、私は、MRI用の並行マーキングGCを作成中です。
現在、 RDoc文書（'make rdoc'を使って）を生成するのに、私のマシンで約80秒かかります。その時間の30％がGCに費やされています。私は、2コアCPUマシンで、何とかこれをざっと40％改善しました。
私は、RubyConf 2011でこれについて話すつもりです。
lazy sweep GCの実装は Rubyの gc.c にあり、特に lazy_sweep と gc_lazy_sweep 関数にある。
Ruby標準ライブラリの変更は、Ruby 1.9.3 Preview 1 Release Notes に記載されている。ライセンスに関係する変更もある。リリースノートによると、「Rubyのライセンスは、 GPLv2 によるデュアルライセンスから 2-clause BSDLによるデュアルライセンスに変更された。」
Ruby 1.9.3もそろそろなので、再び Ruby 1.8.x 対 Ruby 1.9.2の状況を見るべき時である。Rubyをホストする人達は、1.9.xの方向に動いてきている。 Herokuが Cedar stack を導入した。これは彼らのPaaSを動かしている。 Cedarは Ruby 1.9.2版を提供しているが、 1.8.xは提供していない。 Engine Yardの AppCloudは、デフォルトを Ruby 1.9.2にしている。
開発者が1.9.xに移行するのを助けるために、もう一つ中間のリリースが以前計画されたが、 Ruby 1.8.8は、キャンセルされた。Ruby 1.8.6 は、特にライブラリで、かなり後に置かれている。例えば RDoc 3はサポートされない。1.8.7ではサポートされている。
1.9.xをサポートするGemsの状況を、 isitruby19.comで見ることができる。
1.8.xにとどまる理由がありますか？