BT

InfoQ ホームページ ニュース 1.8.xのメモリリークの修正およびパフォーマンスの改善の新たなパッチ

1.8.xのメモリリークの修正およびパフォーマンスの改善の新たなパッチ

ブックマーク

パフォーマンスということになると、現在Ruby 1.9.1およびJRubyは、Ruby実装のパックを先導している。しかしながら、さまざまな理由でこれらRuby実装のいずれかへの遷移は、未だ可能 ではない場合がある。ある分野において、Ruby 1.9.xが1.8.7との互換性がなく、Rubyにネイティブ拡張を使用するRuby libsが欠如しているような理由がある。それを念頭に置くと、MRI 1.8.xは近い将来定着するようである。そこでそのパフォーマンスを向上させることに関心が集まる。

Brent Roman氏は、Ruby 1.8.x MRIに対するパフォーマンスの改善を実現した。Rubyのメモリリークを特に継続的に修正することから開始した(リンク)

基本的な技法は、Kurt Stephens氏が提案したものの改良版である。それは、この1つのライナーのリークを取り除くだけでなく、
loop {@x=callcc{|c|c}}
マルチスレッドのロボット工学アプリケーションのリークも取り除く。Rubyプロセスは、かつては1日で結局20MB以上にまでなった。同様の実行は、今では10MB未満である。

結局のところ、リークは、Rubyの保守的なGCと上手く対話しないGCC最適化が原因である(リンク)

ガベッジコレクターのメモリのリークは、まったくそれ自体の過失ではない。「C」マシンスタックが、オブジェクト参照で溢れていることが問題である。この 主な理由は、GCCコンパイラが非常に大きなスタックフレームを作成し、そこにある多くの値を初期化しないことである。Rubyインタープリターコア再帰 的表現evaluatorで使用される特定の「C」構造体は、特に大きく、まばらなスタックフレームを生成する。関数rb_eval()は、自分自身で数 百回も呼び出すかもしれない関数の起動ごとに、キロバイトサイズのスタックフレームを作成する。これにより、数百キロバイトのスタックになり、たいてい決 してなくなることのない古いオブジェクト参照でいっぱいである。

Brent氏はこれらの問題を修正することを目指しているRuby 1.8.7-patlevel72(リンク)に対し、パッチを提供した。
テスターは、現実世界のRailsアプリケーションを実行する一方で、パッチでの大幅なスピードアップを報告している(リンク)。また問題もいくつか報告された。そこで今後の行方を見守ることにする。

これらのパッチは、MRIを改善しているオープンソース(Ruby)コミュニティの別の例である。Mod_rails (またはREE)(参考記事)は、別の例である。MRIのガベージコレクターをフォークに優しくする(詳しくは、リンクされたニュース項目を参照)。

MRIのパフォーマンスは、コンパイルの様子により大きく変化する(参考記事)

2009年はRuby 1.8.xに固執する計画か?もしそうなら、その主な理由は何か?

 

原文はこちらです:http://www.infoq.com/news/2009/01/ruby-patches-fix-leaks

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。