From: Narihiro Nakamura Date: 2009-12-11T00:02:42+09:00 Subject: [ruby-dev:39867] Re: [Feature #2471] want to choose a GC algorithm nariです。 GCと聞いて来ました。 2009年12月10日9:54 KOSAKI Motohiro : (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)