『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
RubyKaigi 2日目は参加できなかったので、 あちこちのレポートをチェック。
akrさんの「Matzを説得する方法」は普通にオープンソースで自分の要望を通す方法として 有効だと思った。「Perlを出すと通る」というような枝葉は除いて。
authorNariの「RubyのGCを(ry」は誤解を招くと思った。
JRuby, Rubinius, CRubyのGCをそれぞれ
として、CRubyのGCは(形容詞が少ないから)劣っていると思わせるような表現があるが、 それはあまり適切ではない。GCの実装というのはいつもトレードオフだからだ。
前にも書いたがスループットはGC全体の処理時間、 レスポンス(or ポーズタイム)はGC1回によって本来の処理が停止する時間である。
これらは多くの場合トレードオフの関係にある。
incrementalとかgenerationalなGCを実装するためには write barrierという仕組みを入れる必要があるが、 それはほとんどの場合スループットを低下させる。 要するにwrite barrierを入れると遅くなるのだ。
普通の方法ではwrite barrierを入れることによって増大したコストを 穴埋めするほどGC処理効率を改善することはできないし、 card markingなどの手法を使うとこんどはメモリを馬鹿食いする。
CRubyはconservative(保守的な)GCを採用しており、 残りはexact(正確な)GCを採用している。
exactなGCの方が性能的にやや有利だが、 一方、拡張ライブラリの書きやすさは 保守的GCの方がずっと楽である。
たとえば、Rubiniusはexact GCを採用しているため
など、Cでのメソッド定義にかなり制約がある。 まあ、ほとんどのメソッドをRubyで実装しようというRubiniusでなら 受け入れられる制約なのかもしれない。
CRubyは開発効率を重視しているので、 今後も保守的GCを使い続けると思う。
Ruby Enterprise Edition*1でも 指摘されていることだが、サブプロセス間でメモリページが共有されている場合には オブジェクトにできるだけ触らない方がよい。ページのコピーが発生しちゃうから。
ところが、JRubyやRubiniusのcompactを行うGCは、そういう観点からは壊滅的である。 まあ、JavaにはforkはないからJRubyは気にする必要はないのかもしれないけど。
現在のCRubyのGCもcopy-on-writeについて問題はあるけれども、 compactingを行わないので、(REEが使っている)bitmarkingなどの手法で 対応する可能性は残されている。
というわけで、「どんげんかせんといかん」だろうとは思うが、 今のRuby GCが今のようになっているのはそれなりに理由がある、という話。
世代別GCだって、copy-on-write friendlyだって、実際に試してみた上で、 普通のケースで性能低下が発生するので採用していないわけで。
*1 Ruby Enterprise Editionについてはあとで書くつもり
Charlesが来るからオフィスに来て、と言われる。
でかけると、某社社長が松江市の業務システム(Ruby製、一部JRuby入り)について 一生懸命(英語で)説明している。すばらしい。
あと、Charles相手にNaCl対抗将棋戦、囲碁戦が行われる。 将棋はshugoの勝ち、囲碁は時間切れ。
島大で講義。Charlesの講義が聴ける島大生はラッキーだと思うけど、 本人たちがどれだけ自覚しているんだろうか。
懇親会(その前にCharlesたちは千鳥城を見学したらしい)。
NaClの若い衆がCharlesを取り囲んで一生懸命英語で話をしていた。 authorNariはJRubyのGCについて食い下がっていたけど(うーむ)、 「そんなにはJVMに任せているからシラネ」とあしらわれていた(らしい、本人談)。
ケータリングは大変おいしかった。食べ過ぎ。
これからCharlesは福岡→東京と移動するらしい。 うーむ、なんて体力勝負。
This work is licensed under a Creative Commons License.
通りすがりのものですが(^_^;)、<br>GabageCollectionの実装技術なんて、全然勉強した事ないのですが、<br>realtime monitorにぶら下げようと思うと、原理的に難しいだろうなあ…と思ってます。。<br><br>っとなると、embeded systemがOOするのは、未だ先になるのかなあ……
リアルタイム、それもハードリアルタイムを満たすようなGC技術もありますよ。極端にレスポンス重視ということですね。<br>もちろんトレードオフはあってそういうGCは一般にスループットが低いので「普通のGC」として使うのには厳しいのですが。
いやー…考えなる人は考えとうなるですねぇ…<br>それでまた、ユーザーさんの方も、知っとうなる人は知っとうなる、んかな…<br><br>ところで、「レスポンスが速くて、スループットが低い」というのをしばらく考えましたが、<br>イベントに応答して立ち回っているうちに、ジョブの全てが処理しきれるまでにどれくらいのヒマがかかるか保証できない、<br>ってところでしょうか…？
ハードリアルタイムなGCとは、GCによる中断が100usecとかあらかじめ決定された時間内に必ず終了することが保証されているということです。<br>が、そのようなGCアルゴリズムは処理全体に占めるGC時間は長くなりがちです。細切れにたくさん中断するということですね。
>細切れにたくさん中断するということですね。 <br><br>あ。やはりそうですよね。(^_^;)<br><br>それで良いと思うんですが、全ＧＣの終了を時間制限するのではなくとも、<br>interrupt handlerが必要とするメモリ量だけを調達する処理時間の制限をする……<br>ぅ〜なんてことは、なんか、やっぱり、あちこちに差し障りが出そうな気がしてきました……(^_^;)<br><br>＃幸い、私はそういう事は業務に抱えてはおりませんので、どうかお構いなく(^_^;)
http://www.nminoru.jp/~nminoru/java/cms/pauseless_gc.html<br>とかいう激しく強引な"リアルタイム"GCなんてのもあります。