Feature #2471: want to choose a GC algorithm

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 2.0.0

[wanabe (_ wanabe)]

=begin
GC のアルゴリズムを複数用意して、選択可能にするのはどうでしょうか。
パッチを添付します。たたき台にしていただければ幸いです。

選択対象として、authorNari さんの LazySweep
http://www.narihiro.info/resource/patch/rb_gc_lazy_improve.diff
を使わせていただきました。ありがとうございます。
起動時に環境変数 RUBYGC に lazy を代入しておくことで LazySweep が有効になります。

コンパイル時に NOSELECT_GC 定数を定義することで無効にすることも可能です。
関数ポインタを参照するわずかな遅延が許せない人向けに一応用意しましたが、
適切に GC を選択するならばあまり問題にならないのではないかと思います。
=end

[ujihisa (Tatsuhiro Ujihisa)]

• Status changed from Open to Assigned
• Assignee set to matz (Yukihiro Matsumoto)

=begin

=end

[wanabe (_ wanabe)]

=begin
ワナベと申します。

09/12/10 KOSAKI Motohiro [e-mail]:

Feature #2471: want to choose a GC algorithm
GC のアルゴリズムを複数用意して、選択可能にするのはどうでしょうか。

ほとんどのユーザは自分のワークロードに最適なGCを選ぶ十分な情報を
持っていないので、エンドユーザ視点ではあまり意味がない拡張に思えます。
また、オープンソースの性質として安易なワークアラウンドを用意すると適切な
フィードバックが返ってこなくなるのでデフォルトGCの改善が遅れるという
リスクがあります。

これは誰がうれしくなることを意図しているパッチなのでしょうか？

GC に全然詳しくないので、外した事を書いてしまったらすみません。
例えば、アクションゲームを Ruby で作りたい場合は LazySweep を指定したほうがいい
というような定石として広まると面白い、と考えていました。
そういった方がどれだけいるか知りませんが。

というのが建前で、本音は GC 開発者およびその傍観者に嬉しいというのが大きいです。
（この傍観者は、GC に興味があるけれども手は出せない私のような人を指します。）
言われてみると確かに、デフォルト GC の改善の遅れにつながる可能性は否定できません。
しかし、第二、第三の GC の改善にはつながります。

前述の LazySweep を例に取れば、試したい場合は自分でパッチを当てなければならず、
活発に開発されている trunk に追随するのはかなり面倒でした。
そのため広くは使われず（失礼な言い方ですみません）、その結果 nari さんが
デバッグ等ほぼ（すべて？）お一人で完成させたものと認識しています。

どの面においてもデフォルトの GC を超える GC がさっとできればそれでいいのですが
どこかに不利な点があると本採用とはならず、上のように使われず改善も遅れます。

これではあまりに非効率的なので、レポジトリにのせて気軽に試せるようにし
そこで広くデバッグしたほうがいいのではないか、というのが趣旨です。
そうしていずれデフォルトが置き換えられるかもしれませんし、そうでもないかもしれません。
置き換えられなかったとしても、一番最初に挙げたように有用な局面が Tips 的に広まれば
それはそれで価値があると思います。

--
ワナベ

=end

[authorNari (Narihiro Nakamura)]

=begin
nariです。

GCと聞いて来ました。

2009年12月10日9:54 KOSAKI Motohiro [e-mail]:
(snip)

GC のアルゴリズムを複数用意して、選択可能にするのはどうでしょうか。
パッチを添付します。たたき台にしていただければ幸いです。

選択対象として、authorNari さんの LazySweep
http://www.narihiro.info/resource/patch/rb_gc_lazy_improve.diff
を使わせていただきました。ありがとうございます。
起動時に環境変数 RUBYGC に lazy を代入しておくことで LazySweep が有効になります。

コンパイル時に NOSELECT_GC 定数を定義することで無効にすることも可能です。
関数ポインタを参照するわずかな遅延が許せない人向けに一応用意しましたが、
適切に GC を選択するならばあまり問題にならないのではないかと思います。

[脱線タイムスタート]

ほとんどのユーザは自分のワークロードに最適なGCを選ぶ十分な情報を
持っていないので、エンドユーザ視点ではあまり意味がない拡張に思えます。

[私もちょっと脱線します…]

私はアプリケーションによってユーザがGCを選択できることに意味があると思
います。なぜなら、すべてのGCアルゴリズムには一長一短があり、アプリケー
ションによってはGCアルゴリズム自体を取り替えた方がよいケースが確実にあ
るからです。

「ほとんどのユーザは最適なGCを選ぶ十分な情報をもっていない」というより
も「情報を得ようとしない」というのが正しいのではないでしょうか。そのよ
うなユーザにとってGCのアルゴリズムは特に関係なく、「GCさえあれば満足」
という気持ちなのだと想像します。
このようなユーザにとってGCの選択性はまったく意味はないでしょう。ただ、
GCの選択性による害があるかというと、それもない気がします。

GCが選択できて嬉しいユーザというのは、実際にGCによって困った状態に陥っ
ているユーザだと思います。例えば、リアルタイム性を求めるアプリケーショ
ンでGCのStopTheWorldに苦しんでいるとか…。そのとき、ユーザが気軽にGCの
アルゴリズムを変更できるのはよいことだと思います。

また、オープンソースの性質として安易なワークアラウンドを用意すると適切な
フィードバックが返ってこなくなるのでデフォルトGCの改善が遅れるという
リスクがあります。

あ、なるほど。そのような側面もあるのですね。たしかに、ユーザからのバグ
の発見などは遅れそうですね。テストも難しそうです。HotspotVMなんかは4個
くらいのまったく違うGCアルゴリズムが入っていますが、あれもメンテナンス
が大変そうですね（マンパワーが違うのでしょうか…）。

ただ、GC自体の改善（高速化等）という観点で見ると、今までのCRubyのGCはそ
れほど大きな改善はなされていないので、特にこのパッチが入ることによって、
さらに改善が遅くなるということもないのではないかと思います。
逆にLazySweepが上手く育ってくれれば、デフォルトのGCに取って代わるという
のも面白いかもしれません。

--
Narihiro Nakamura (nari)

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:39867] Re: [Feature #2471] want to choose a GC algorithm"
on Fri, 11 Dec 2009 00:02:42 +0900, Narihiro Nakamura [e-mail] writes:

|ただ、GC自体の改善（高速化等）という観点で見ると、今までのCRubyのGCはそ
|れほど大きな改善はなされていないので、特にこのパッチが入ることによって、
|さらに改善が遅くなるということもないのではないかと思います。
|逆にLazySweepが上手く育ってくれれば、デフォルトのGCに取って代わるという
|のも面白いかもしれません。

っていうか、LazySweepって「取って代わる」ような大きなアルゴリ
ズムの変更ではないと思います。あまり大きなトレードオフもなさ
そうなので、ちゃんとバグが取れたならいつも有効にしていてもよ
いような。

そういう意味では、LazySweepがon/offできることのメリットが不明
なので、このパッチには賛成しません。これがcopy-on-write
friendly GCとかmostly-copying GCのような性能特性が大きく変わ
りそうなものなら、切り替えに意味があるかもしれません。

GCについては、

• ささだくんのところのメモリアロケーションにmmapを使う改善
• その応用としてのビットマップマーキング
• LazySweep

がとりあえず有望そうな改善だと思います。今後の課題としては

• multi threadedなsweep
• 鵜川さんのところのmostly-copying GC
• ライトバリアの導入

などが考えられますが、これらは解決すべき課題がまだまだ多そう
です。

                             まつもと ゆきひろ /:|)

=end

[authorNari (Narihiro Nakamura)]

=begin
nari です。

2009年12月11日1:14 Yukihiro Matsumoto [e-mail]:

まつもと ゆきひろです

In message "Re: [ruby-dev:39867] Re: [Feature #2471] want to choose a GC algorithm"
on Fri, 11 Dec 2009 00:02:42 +0900, Narihiro Nakamura [e-mail] writes:

|ただ、GC自体の改善（高速化等）という観点で見ると、今までのCRubyのGCはそ
|れほど大きな改善はなされていないので、特にこのパッチが入ることによって、
|さらに改善が遅くなるということもないのではないかと思います。
|逆にLazySweepが上手く育ってくれれば、デフォルトのGCに取って代わるという
|のも面白いかもしれません。

っていうか、LazySweepって「取って代わる」ような大きなアルゴリ
ズムの変更ではないと思います。あまり大きなトレードオフもなさ
そうなので、ちゃんとバグが取れたならいつも有効にしていてもよ
いような。

そういう意味では、LazySweepがon/offできることのメリットが不明
なので、このパッチには賛成しません。これがcopy-on-write
friendly GCとかmostly-copying GCのような性能特性が大きく変わ
りそうなものなら、切り替えに意味があるかもしれません。

なるほど。確かにそうですね。
LazySweepのパッチはバグが取れていたと思うので、trunkに合わせた
ものを作って、再度MLに投稿します。

--
Narihiro Nakamura (nari)

=end

[wanabe (_ wanabe)]

• Status changed from Assigned to Rejected

=begin
LazySweep ではスループットが増大するという話をどこかで聞いた覚えがあって
それが理由で trunk に入らないのかと思っていました。
入らなかったのは単にバグの問題で、すでに解決されているということなので
チケットは Reject させていただきます。ありがとうございました。
=end

[wanabe (_ wanabe)]

• File extgc.patch extgc.patch added
• Status changed from Rejected to Open
• Target version changed from 1.9.2 to 2.0.0

=begin
ずいぶん前のチケットですみませんが、趣旨が同じなのでreopen させて頂きます。

copy-on-write friendly GCとかmostly-copying GCのような性能特性が大きく変わ
りそうなものなら、切り替えに意味があるかもしれません。

とのことなので、BitmapMarking でパッチを書いてみました。
前回と同じく nari さんの実装を使わせていただきました。ありがとうございます。
また、静的リンクせずに拡張ライブラリと同じ .so 形式でロードするようにしました。
例えば ruby -I .ext/i686-linux -G gc_bmp test.rb などとすると読み込まれると思います。
prelude 前に確定させなければならないので、gem のロードパスには対応できませんでした。

rb_gc_load を筆頭に実装がいろいろひどいので、整理してからと思っていたのですが
自分ではこれ以上どうすることもできなそうなのでとりあえずチケットとして残させて頂きます。すみません。
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

=begin

=end

[matz (Yukihiro Matsumoto)]

• Description updated (diff)
• Status changed from Assigned to Rejected

切替えに伴うコスト増が正当化できないと思うので、このままでは採用しません。
だれかが性能に優れたパッチを書いてくれたら別ですが。