https://redmine.ruby-lang.org/
https://redmine.ruby-lang.org/favicon.ico?1711330511
2009-12-10T09:47:11Z
Ruby Issue Tracking System
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=7271
2009-12-10T09:47:11Z
ujihisa (Tatsuhiro Ujihisa)
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>matz (Yukihiro Matsumoto)</i></li></ul><p>=begin</p>
<p>=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=7273
2009-12-10T19:06:39Z
wanabe (_ wanabe)
s.wanabe@gmail.com
<ul></ul><p>=begin<br>
ワナベと申します。</p>
<p>09/12/10 KOSAKI Motohiro <a href="mailto:kosaki.motohiro@jp.fujitsu.com" class="email">kosaki.motohiro@jp.fujitsu.com</a>:</p>
<blockquote>
<blockquote>
<p>Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: want to choose a GC algorithm (Rejected)" href="https://redmine.ruby-lang.org/issues/2471">#2471</a>: want to choose a GC algorithm<br>
GC のアルゴリズムを複数用意して、選択可能にするのはどうでしょうか。</p>
</blockquote>
</blockquote>
<blockquote>
<p>ほとんどのユーザは自分のワークロードに最適なGCを選ぶ十分な情報を<br>
持っていないので、エンドユーザ視点ではあまり意味がない拡張に思えます。<br>
また、オープンソースの性質として安易なワークアラウンドを用意すると適切な<br>
フィードバックが返ってこなくなるのでデフォルトGCの改善が遅れるという<br>
リスクがあります。</p>
<p>これは誰がうれしくなることを意図しているパッチなのでしょうか?</p>
</blockquote>
<p>GC に全然詳しくないので、外した事を書いてしまったらすみません。<br>
例えば、アクションゲームを Ruby で作りたい場合は LazySweep を指定したほうがいい<br>
というような定石として広まると面白い、と考えていました。<br>
そういった方がどれだけいるか知りませんが。</p>
<p>というのが建前で、本音は GC 開発者およびその傍観者に嬉しいというのが大きいです。<br>
(この傍観者は、GC に興味があるけれども手は出せない私のような人を指します。)<br>
言われてみると確かに、デフォルト GC の改善の遅れにつながる可能性は否定できません。<br>
しかし、第二、第三の GC の改善にはつながります。</p>
<p>前述の LazySweep を例に取れば、試したい場合は自分でパッチを当てなければならず、<br>
活発に開発されている trunk に追随するのはかなり面倒でした。<br>
そのため広くは使われず(失礼な言い方ですみません)、その結果 nari さんが<br>
デバッグ等ほぼ(すべて?)お一人で完成させたものと認識しています。</p>
<p>どの面においてもデフォルトの GC を超える GC がさっとできればそれでいいのですが<br>
どこかに不利な点があると本採用とはならず、上のように使われず改善も遅れます。</p>
<p>これではあまりに非効率的なので、レポジトリにのせて気軽に試せるようにし<br>
そこで広くデバッグしたほうがいいのではないか、というのが趣旨です。<br>
そうしていずれデフォルトが置き換えられるかもしれませんし、そうでもないかもしれません。<br>
置き換えられなかったとしても、一番最初に挙げたように有用な局面が Tips 的に広まれば<br>
それはそれで価値があると思います。</p>
<p>--<br>
ワナベ</p>
<p>=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=7276
2009-12-11T00:03:00Z
authorNari (Narihiro Nakamura)
authorNari@gmail.com
<ul></ul><p>=begin<br>
nariです。</p>
<p>GCと聞いて来ました。</p>
<p>2009年12月10日9:54 KOSAKI Motohiro <a href="mailto:kosaki.motohiro@jp.fujitsu.com" class="email">kosaki.motohiro@jp.fujitsu.com</a>:<br>
(snip)</p>
<blockquote>
<blockquote>
<p>GC のアルゴリズムを複数用意して、選択可能にするのはどうでしょうか。<br>
パッチを添付します。たたき台にしていただければ幸いです。</p>
<p>選択対象として、authorNari さんの LazySweep<br>
<a href="http://www.narihiro.info/resource/patch/rb_gc_lazy_improve.diff" class="external">http://www.narihiro.info/resource/patch/rb_gc_lazy_improve.diff</a><br>
を使わせていただきました。ありがとうございます。<br>
起動時に環境変数 RUBYGC に lazy を代入しておくことで LazySweep が有効になります。</p>
<p>コンパイル時に NOSELECT_GC 定数を定義することで無効にすることも可能です。<br>
関数ポインタを参照するわずかな遅延が許せない人向けに一応用意しましたが、<br>
適切に GC を選択するならばあまり問題にならないのではないかと思います。</p>
</blockquote>
<p>[脱線タイムスタート]</p>
<p>ほとんどのユーザは自分のワークロードに最適なGCを選ぶ十分な情報を<br>
持っていないので、エンドユーザ視点ではあまり意味がない拡張に思えます。</p>
</blockquote>
<p>[私もちょっと脱線します…]</p>
<p>私はアプリケーションによってユーザがGCを選択できることに意味があると思<br>
います。なぜなら、すべてのGCアルゴリズムには一長一短があり、アプリケー<br>
ションによってはGCアルゴリズム自体を取り替えた方がよいケースが確実にあ<br>
るからです。</p>
<p>「ほとんどのユーザは最適なGCを選ぶ十分な情報をもっていない」というより<br>
も「情報を得ようとしない」というのが正しいのではないでしょうか。そのよ<br>
うなユーザにとってGCのアルゴリズムは特に関係なく、「GCさえあれば満足」<br>
という気持ちなのだと想像します。<br>
このようなユーザにとってGCの選択性はまったく意味はないでしょう。ただ、<br>
GCの選択性による害があるかというと、それもない気がします。</p>
<p>GCが選択できて嬉しいユーザというのは、実際にGCによって困った状態に陥っ<br>
ているユーザだと思います。例えば、リアルタイム性を求めるアプリケーショ<br>
ンでGCのStopTheWorldに苦しんでいるとか…。そのとき、ユーザが気軽にGCの<br>
アルゴリズムを変更できるのはよいことだと思います。</p>
<blockquote>
<p>また、オープンソースの性質として安易なワークアラウンドを用意すると適切な<br>
フィードバックが返ってこなくなるのでデフォルトGCの改善が遅れるという<br>
リスクがあります。</p>
</blockquote>
<p>あ、なるほど。そのような側面もあるのですね。たしかに、ユーザからのバグ<br>
の発見などは遅れそうですね。テストも難しそうです。HotspotVMなんかは4個<br>
くらいのまったく違うGCアルゴリズムが入っていますが、あれもメンテナンス<br>
が大変そうですね(マンパワーが違うのでしょうか…)。</p>
<p>ただ、GC自体の改善(高速化等)という観点で見ると、今までのCRubyのGCはそ<br>
れほど大きな改善はなされていないので、特にこのパッチが入ることによって、<br>
さらに改善が遅くなるということもないのではないかと思います。<br>
逆にLazySweepが上手く育ってくれれば、デフォルトのGCに取って代わるという<br>
のも面白いかもしれません。</p>
<p>--<br>
Narihiro Nakamura (nari)</p>
<p>=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=7277
2009-12-11T01:14:22Z
matz (Yukihiro Matsumoto)
matz@ruby.or.jp
<ul></ul><p>=begin<br>
まつもと ゆきひろです</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-dev/39867">[ruby-dev:39867]</a> Re: [Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: want to choose a GC algorithm (Rejected)" href="https://redmine.ruby-lang.org/issues/2471">#2471</a>] want to choose a GC algorithm"<br>
on Fri, 11 Dec 2009 00:02:42 +0900, Narihiro Nakamura <a href="mailto:authornari@gmail.com" class="email">authornari@gmail.com</a> writes:</p>
<p>|ただ、GC自体の改善(高速化等)という観点で見ると、今までのCRubyのGCはそ<br>
|れほど大きな改善はなされていないので、特にこのパッチが入ることによって、<br>
|さらに改善が遅くなるということもないのではないかと思います。<br>
|逆にLazySweepが上手く育ってくれれば、デフォルトのGCに取って代わるという<br>
|のも面白いかもしれません。</p>
<p>っていうか、LazySweepって「取って代わる」ような大きなアルゴリ<br>
ズムの変更ではないと思います。あまり大きなトレードオフもなさ<br>
そうなので、ちゃんとバグが取れたならいつも有効にしていてもよ<br>
いような。</p>
<p>そういう意味では、LazySweepがon/offできることのメリットが不明<br>
なので、このパッチには賛成しません。これがcopy-on-write<br>
friendly GCとかmostly-copying GCのような性能特性が大きく変わ<br>
りそうなものなら、切り替えに意味があるかもしれません。</p>
<p>GCについては、</p>
<ul>
<li>ささだくんのところのメモリアロケーションにmmapを使う改善</li>
<li>その応用としてのビットマップマーキング</li>
<li>LazySweep</li>
</ul>
<p>がとりあえず有望そうな改善だと思います。今後の課題としては</p>
<ul>
<li>multi threadedなsweep</li>
<li>鵜川さんのところのmostly-copying GC</li>
<li>ライトバリアの導入</li>
</ul>
<p>などが考えられますが、これらは解決すべき課題がまだまだ多そう<br>
です。</p>
<pre><code> まつもと ゆきひろ /:|)
</code></pre>
<p>=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=7279
2009-12-11T09:25:40Z
authorNari (Narihiro Nakamura)
authorNari@gmail.com
<ul></ul><p>=begin<br>
nari です。</p>
<p>2009年12月11日1:14 Yukihiro Matsumoto <a href="mailto:matz@ruby-lang.org" class="email">matz@ruby-lang.org</a>:</p>
<blockquote>
<p>まつもと ゆきひろです</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-dev/39867">[ruby-dev:39867]</a> Re: [Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: want to choose a GC algorithm (Rejected)" href="https://redmine.ruby-lang.org/issues/2471">#2471</a>] want to choose a GC algorithm"<br>
on Fri, 11 Dec 2009 00:02:42 +0900, Narihiro Nakamura <a href="mailto:authornari@gmail.com" class="email">authornari@gmail.com</a> writes:</p>
<p>|ただ、GC自体の改善(高速化等)という観点で見ると、今までのCRubyのGCはそ<br>
|れほど大きな改善はなされていないので、特にこのパッチが入ることによって、<br>
|さらに改善が遅くなるということもないのではないかと思います。<br>
|逆にLazySweepが上手く育ってくれれば、デフォルトのGCに取って代わるという<br>
|のも面白いかもしれません。</p>
<p>っていうか、LazySweepって「取って代わる」ような大きなアルゴリ<br>
ズムの変更ではないと思います。あまり大きなトレードオフもなさ<br>
そうなので、ちゃんとバグが取れたならいつも有効にしていてもよ<br>
いような。</p>
<p>そういう意味では、LazySweepがon/offできることのメリットが不明<br>
なので、このパッチには賛成しません。これがcopy-on-write<br>
friendly GCとかmostly-copying GCのような性能特性が大きく変わ<br>
りそうなものなら、切り替えに意味があるかもしれません。</p>
</blockquote>
<p>なるほど。確かにそうですね。<br>
LazySweepのパッチはバグが取れていたと思うので、trunkに合わせた<br>
ものを作って、再度MLに投稿します。</p>
<p>--<br>
Narihiro Nakamura (nari)</p>
<p>=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=7281
2009-12-11T12:50:47Z
wanabe (_ wanabe)
s.wanabe@gmail.com
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Rejected</i></li></ul><p>=begin<br>
LazySweep ではスループットが増大するという話をどこかで聞いた覚えがあって<br>
それが理由で trunk に入らないのかと思っていました。<br>
入らなかったのは単にバグの問題で、すでに解決されているということなので<br>
チケットは Reject させていただきます。ありがとうございました。<br>
=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=9608
2010-04-01T00:01:47Z
wanabe (_ wanabe)
s.wanabe@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/918">extgc.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/918/extgc.patch">extgc.patch</a> added</li><li><strong>Status</strong> changed from <i>Rejected</i> to <i>Open</i></li><li><strong>Target version</strong> changed from <i>1.9.2</i> to <i>2.0.0</i></li></ul><p>=begin<br>
ずいぶん前のチケットですみませんが、趣旨が同じなのでreopen させて頂きます。</p>
<blockquote>
<p>copy-on-write friendly GCとかmostly-copying GCのような性能特性が大きく変わ<br>
りそうなものなら、切り替えに意味があるかもしれません。</p>
</blockquote>
<p>とのことなので、BitmapMarking でパッチを書いてみました。<br>
前回と同じく nari さんの実装を使わせていただきました。ありがとうございます。<br>
また、静的リンクせずに拡張ライブラリと同じ .so 形式でロードするようにしました。<br>
例えば ruby -I .ext/i686-linux -G gc_bmp test.rb などとすると読み込まれると思います。<br>
prelude 前に確定させなければならないので、gem のロードパスには対応できませんでした。</p>
<p>rb_gc_load を筆頭に実装がいろいろひどいので、整理してからと思っていたのですが<br>
自分ではこれ以上どうすることもできなそうなのでとりあえずチケットとして残させて頂きます。すみません。<br>
=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=13343
2010-09-14T16:09:33Z
shyouhei (Shyouhei Urabe)
shyouhei@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li></ul><p>=begin</p>
<p>=end</p>
Ruby master - Feature #2471: want to choose a GC algorithm
https://redmine.ruby-lang.org/issues/2471?journal_id=28023
2012-07-14T14:16:58Z
matz (Yukihiro Matsumoto)
matz@ruby.or.jp
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/28023/diff?detail_id=20687">diff</a>)</li><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Rejected</i></li></ul><p>切替えに伴うコスト増が正当化できないと思うので、このままでは採用しません。<br>
だれかが性能に優れたパッチを書いてくれたら別ですが。</p>