RubyのGC改善による私のエコライフ

RubyのGC改善による私のエコライフレジ袋は結構ですよ(2009夏) nari ネットワーク応用通信研究所 Powered by Rabbit 0.6.1

先に

お詫びいまからCRuby内部の大変マニアックな話をします

しかも30分も

m(_ _)m

今日話す内容 CRubyのGCを改善しましたというお話し GC = ゲームキューブ？今日の話にはついていけません 5/148

今日話す内容 GC改善 = ゴミ処理機性能アップなんとなくエコっぽい流行ってるしなんとなくタイトルに 6/148

アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 7/148

自己紹介

自己紹介 nariと申します id:authorNari(はてな) nari3(twitter) 量産型中村 10/148

自己紹介ネットワーク応用通信研究所に所属島根の方から来ました元アイス工場勤務，現NaCl勤務注：NaClにアイス工場支社はない「RailsのWebアプリを受託開発」などなどお仕事募集中 11/148

自己紹介無類のGC好き「CRubyGCについて考えたりするコミッタ」 12/148

宣伝(1)

絶対復習というサービス Railsで作ってます復習を促進するサービス復讐は促進しません＞＜詳細は割愛 15/148

続きはWEBで 16/148

宣伝(2)

GCは作らない

巻末 GCはこれほど知られているのに日本語でGCについて執筆された本がない 20/148

数少ない GCファンに朗報!!

なんとGC本執筆中

内容アルゴリズムの話実装の話 Pythonの.. androidの.. v8の.. rub..niusの.. 監修は超大物 23/148

問題誰が買うの？今のところ笹田研のささだ先生が有力候補 24/148

宣伝はこれくらいで..

恒例のアンケート

GCに興味ある方？ノシ

gc.cを読んだ事がある方？ノシ

GC本が出たらかうよ！って人？ノシ

予想...5人

CRubyのGC改善とエコ

GCとエコの密着した関連性をお話ししましょう

GCとエコの関連性 CRubyGCを改善する世界の RubyHacker のPCの熱量が1%下がるとする Rubyに費やす1ヶ月の電気使用量100円 1円分お得 => 1円分エコ 34/148

GCとエコの関連性世界にはRubyプログラマ何人くらいいるだろう？まぁ，100万人くらいとしよう 100万人 X 2円 => 月間200万円エコ年間2400万円エコ 35/148

ルピィに換算ルピィに換算（インドの通貨） 3円 => 1ルピィ年間約800万ルピィ 36/148

GCを改善すれば年間約800万ルピィ分のエコができますね！

現在のCRubyGC概要

現在のCRubyのGC

マークスイープ方式

CRubyのヒープ構造 malloc にて 16Kバイトのメモリ領域を確保ヒープスロット 42/148

CRubyのヒープ構造オブジェクトの配列を作成オブジェクトサイズの20バイトでアラインメントオブジェクトはそれぞれフリーリストでつながっ 43/148 ている

オブジェクトの割り当て 1. 処理系から割り当て要求 2. フリーリストからオブジェクトを一つ取り出し 3. 取り出したオブジェクトを初期化 44/148

マーク処理 1. フリーリストが尽きるとマーク処理開始 2. プログラムから見える範囲のオブジェクトを再帰的にマーク 3. マーク処理は各オブジェクト内フラグのマークビットを1にする 4. 全てのルートに対してマークを終えるとマーク処理終了 45/148

スイープ処理 1. ヒープ内のすべてのオブジェクトを走査 2. マークされているオブジェクトはそのマークを消す 3. マークされてないオブジェクトはゴミと見なし，スイープ処理を行う 4. ヒープ内を全て走査し終わるとスイープ処理終了 46/148

シンプルなマークスイープの実装

マーク(印付け)してスイープ(掃除)する

ここは雰囲気だけつかんで貰えば

問題点その1

CopyOnWrite

CopyOnWrite 多くのLinux環境では子プロセス作成時 (fork)のメモリは共有領域に置かれる書き込みがあった際に，それぞれのプロセスの私有領域にコピーされる（注）Rubyの機能ではない 53/148

子プロセス生成時のメモリ領域 54/148

実際にはコピーしない読み込みをする時はそれでも充分 55/148

書き込み(write)が発生 56/148

そのタイミングで私有領域に Copy 57/148

Writeの時に

Copyする

CopyOnWrite

実はCRubyGCと CopyOnWriteは相性が悪い

無駄なコピーの発生 CRubyGCではマークの際に生存している全てのオブジェクトに対して印付けするつまりWriteする forkしたプロセスの場合，CopyOnWriteが効いて無駄なコピーが．． 62/148

無駄なコピーの発生 63/148

エコ活動その1

BitmapMarkingGC オブジェクトの印付け用bitのみを別の領域に移すこれをビットマップと呼ぶオブジェクトの生存，死亡はビットマップにて管理マーク時に直接オブジェクトを操作する事がなくなる無駄なコピーが発生しにくい 66/148

Bitmap領域を確保 Bitmapは非常に小さいサイズ 67/148

そこに印付けする Copyが発生しない 68/148

BitmapMarkingGC導入前例 RubyEnterpriseEditionというRuby実装 (REE) Hongli Laiさん達によって作成 REEと呼ばれる 69/148

REEとは？ Apache+passenger 用のRuby処理系 ruby1.8.6ベース Apache が fork() してリクエスト捌いてる GCをBitmapMarkingGC 70/148

REEでの改善 RubyOnRails+REE+Apacheで動作させたリクエスト毎秒 22％が高速化総メモリ使用量が 31％削減した 71/148

じゃあ，これを本家に取り込んじゃおうよ！

ちょっと問題が…

ビットマップ位置探索それぞれのヒープスロットにビットマップ領域がある 74/148

ビットマップ位置探索 75/148

ビットマップ位置探索オブジェクトのアドレス->Rubyのヒープスロット 76/148

ビットマップ位置の探索をどうしよう？オブジェクトのアドレスしか渡ってこないアドレスから紐付くヒープスロットを見つけなければならない． 77/148

単純に考えるオブジェクトにスロットを指すポインタをもうける 78/148

駄目，絶対ヒープ領域が大きくなりメモリ消費量が大きくなってしまうせっかく1.9でオブジェクトをダイエットしたのに.. 色んな人から怒られる 79/148

REEはどうするか

線形探索ちょ，線形探索ですか＞＜ 81/148

問題点：遅いビットマップ位置探索に線形探索を使用している forkしないプログラムの場合，GCがビットマップマーキング処理の分遅くなる 82/148

REEは1.8系なのでセーフ 1.8系のRubyヒープスロットは1.8倍で大きくなるヒープスロットはまぁ増えても20個とかそのくらい 83/148

1.9系ではアウト 1.9系はRubyヒープスロットのサイズが固定 84/148

1.9系ではアウト Rubyヒープスロット自体を増やす 1.8系で10個 => 1.9系だと357個これだと線形探索はつらくなってくる 1.9に適した探索法を見つける必要があるそのまま取り込めないね… 85/148

アイデア

アライメントを利用すればいいじゃないか

基本的なアイデアヒープスロットサイズは16KB 16KB = 2の14乗 0b100000000000000 88/148

基本的なアイデア下位14bitが全て0のアドレスがヒープスロット内のどこかに存在するはず 89/148

基本的なアイデア 90/148

ビットマップ位置探索アドレスが 0b10101010111010000 91/148

ビットマップ位置探索マスクする 0b10101010111010000 & 0b11100000000000000 0b101000000000000000 92/148

ビットマップ位置探索ビットマップ位置が探索可能 93/148

問題解決 O(n)からO(1)へ大分早くなった 94/148

ただしやっぱり少しだけ遅い

ベンチマーク結果 skk.rb ベンチマーク（自作） 96/148

詳細は論文で！ http://www.narihiro.info/ まつもとさんと連名！ 97/148

このパッチの行方一応まつもとさんのパッチ袋へそのまま永眠かな.. fork()なんて..別にいいし.. 98/148

（´・ω・）...

さぁ，気を取り直して他の問題点を探そうじゃないか！

ちなみにAndroid DalvikVM これと全く同じ問題があるマルチタスク => いっぱい fork() BitmapMarkingが必要になる 101/148

問題点その2

長寿命オブジェクト問題

RubyOnRailsの Rubyヒープ使い方を調査してみた

結果 106/148

構文木オブジェクトが半数を占めていた

構文木オブジェクトって？

何かがおかしい… YARV命令列にしたら構文木オブジェクトはいらない自然にGCされるはずずっと生きているのは何でだろう？ 113/148

さらに調査以下の種類の構文木オブジェクトが多かった 1. NODE_WHILE 2. NODE_METHOD 3. NODE_FBODY 4. NODE_CFUNC 114/148

メソッドで使われる構文木 NODE_METHOD,NODE_FBODY,NODE _CFUNC これらはメソッド生成時に使用＆保持長寿命 115/148

NODE_WHILE YARV内のインラインキャッシュ（最適化）に使用長寿命 116/148

長寿命なオブジェクトが半数を占める半分は無駄なマークになるスイープはあんまり関係ない 117/148

エコ活動その2

まず，まつもとさんに相談昔は構文木オブジェクトはGCの対象じゃなかったどこかで面倒になってGCの対象にしちゃった構文木の部分だけ世代別にしたらどう？ 120/148

おぉ！なるほど！

長寿命GC （勝手に命名）

長寿命GC 123/148

長寿命GC 124/148

メリットマークするオブジェクトが減るベンチマークが遅くならない make benchmark 125/148

デメリットベンチマークがぐんと早くはならない make benchmark ちょっぴり早い 126/148

ライトバリア問題もクリア構文木オブジェクトはRubyレベルから参照出来ないライトバリアを入れるのがコア内部で完結 Cの拡張ライブラリとか考えなくていい 127/148

効果のあったベンチマーク ao-bench id:hogelogさん，id:miura1729さんに測っていただきました 128/148

パッチのその後 trunkに無事取り込まれた色々改良してきたけど初採用感激(T.T) 131/148

が，，

反応この辺のインラインキャッシュやらノードとかその辺は，GC 対象外領域にしてしまおうと思っています． by ささださん 133/148

（´・ω・）...

Rejectされる日は近い

話の続き

昨日の懇親会この辺はGC対象外にしたよ！あれはバグを生むし，とっちゃおうよ by ささださん 137/148

（´・ω・）...

早めにReject しますね！

カバレッジも100%に！

CRubyGCの今後

個人的にやりたい事(1) 色々な処理系のGCいいとこ取り執筆の関係で色々なGCを読んでいるので CRubyに使えそうなのはメモってる 143/148

個人的にやりたい事(2) BoehmGCを適用してみる運動一応動くようにしたすごく遅くなったちょっとチューニングする必要があるかな... 144/148

まとめエコ活動しましたなんやかんやで何も成果がありませんでした先生の次回作にご期待ください 145/148

提供 (株)ネットワーク応用通信研究所

ご静聴ありがとうございました

質疑応答タイム

http://d.hatena.ne.jp	270
http://coderwall.com	12
http://www.slideshare.net	10
http://paper.li	2
https://pub.cozmixng.org	1
http://a0.twimg.com	1

RubyのGC改善による私のエコライフ

by authorNari on Jul 18, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 296

Statistics

RubyのGC改善による私のエコライフ — Presentation Transcript