Go言語のリアルタイムGC 理論と実践 | POSTD
(編注：誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「本当にGoを使えば実現できるのか？ もしできるならどうやって？」 このブログ記事ではGoのガベージコレクタを、どのように機能し（トリコロールアルゴリズム）、なぜ機能し（こんなに短いGCによる一時停止時間の実現）、そして何よりも、それが機能するのかどうか（GCによる
Feature #9634: [PATCH]Symbol GC - Ruby master - Ruby Issue Tracking System
I've written a patch to collect most symbols. PATCH: https://github.com/authorNari/ruby/compare/4a91fb7a45f0e3c...symbol_gc.patch Summary¶ Most symbols in Ruby level are GC-able（generated by #to_sym, #intern, etc..） Exclude a symbol which is translated ID in C-level from GC-able symbols Keep Ruby's C extension compatibility Pass make test-all Benchmark¶ A benchmark program is here. obj = Object.ne
徹底解剖「G1GC」実装編（β版）
本書はOpenJDK7のG1GCの実装と、それに関連する技術を解説します。 目次 スポンサーのみなさま はじめに 1.準備 2.オブジェクト管理機能 3.アロケータ 4.ヒープ構造 5.オブジェクト構造 6.HotspotVMのスレッド管理 7.スレッドの排他制御 8.GCスレッド（並列編） 9.GCスレッド（並行編） 10.並行マーキング 11.退避 12.予測とスケジューリング 13.正確なGCへの道 14.ライトバリアのコスト さらに勉強したい人へ その他参考文献 以下から（ある時点で）最新のebookをダウンロードできます。 徹底解剖「G1GC」実装編-20120915.epub 徹底解剖「G1GC」実装編-20120914.mobi 徹底解剖「G1GC」実装編-20120914.pdf 謝辞 本書はスポンサーのみなさまの金銭的支援によって執筆されました。 スポンサーのみなさま あ
SGenを詳解してみるシリーズ
原文1、 原文2、 原文3 更新 2011/02/27 fililさんからのご指摘でtypoを修正。TODO部分に対して、考えていただいた訳を反映。 更新 2011/02/14 miura1729さんからのご指摘で誤訳を修正 翻訳: 中村 成洋 SGenは、我々が2年間熱心に取り組み、ここ数ヶ月の間で安定性と十分な競争力を持ってきた、Monoの新しいGCです。 これからの一連のブログの記事として、このGCの一般的な働きと、特別な働き、どのようにしてこのGCがベストな性能をえられるかを紹介し、そして最後に未来のプランを説明します。 なぜ新しいGCなのか？ 多くのGC付きのランタイムのように、Monoは開発当時からBoehm-Demers-Weiser collectorを使っていた。以降、これをBoehmと略します。 Boehmの基本的な利点は移植性と安定性があり、楽に組み込むことができる点
Is there a way to profile ruby 1.9.2 scripts with memory allocation reports?
I'm running into bottlenecks in my ruby application, but I can't figure out where it's slowing down. I found memprof, but it doesn't support 1.9. I also found ruby-prof which seems to work fine on 1.9.2, but the memory allocation requires a patched ruby interpreter and I can only find patches for ruby 1.8. Is there a ruby profiler out there that does the job?
いらないキャッシュを消すとRubyスクリプトが速くなる - 2011-11-24 - ククログ
いらないキャッシュを消すことでRubyスクリプトが倍速で動作するようになった話です。 先日、るりまサーチをRackspaceのクラウドサーバー（メモリ1GB）からさくらのVPS 512（メモリ512MB）に移行しました。理由はRackspaceのサーバーが遠くにあるのでレスポンスがもっさりするからです。最速検索がウリなのにこれでは遅いのでないかと誤解されてしまいます。さくらのVPSにしたら近くにあるためサクサクとレスポンスが返ってくるようになりました。しかも、リソース（主にメモリ量）はスケールダウンしているのにです。 るりまサーチはバックエンドの全文検索エンジンgroongaが高速に動作するのとそれほどアクセスがない（！）ため、CPUやI/Oがネックになることはありません。それよりも、ほとんどメモリを搭載していないマシンで動かしているため、ボトルネックになるとすればメモリです。実メモリ以上
Why You Should Be Excited About Garbage Collection in Ruby 2.0 - Pat Shaughnessy
While not very glamorous, Bitmap Marking Garbage Collection is a dramatic, creative innovation! You may have heard last week how Innokenty Mihailov’s great Enumerable::Lazy feature was accepted into the Ruby 2.0 code base. But you may not have heard about an even more significant change that was merged into Ruby 2.0 in January: a new algorithm for garbage collection called “Bitmap Marking.” The de
Android-4.0.1_r1のソースをダウンロードしてみた - コンピュータを楽しもう！！
せっかく、Ice Cream Sandwichのソース公開されたので、「よーし、どこよりも早いコードレビューだぁ」ということで、忙しくて全然ソースを見ている時間が無いのですが、ちょっとダウンロードしてみました。 どこが変わっているか、まぁ、一番興味のあるところは、当然、Dalvikくんですよね。ということで見てみましょう。 おぉ、dalvikvmですが、どこが変わったか差分とってみようと思ったのです。そしたら、こんなことに。分かりますよねぇ。.c がすべて.cpp になっています。 そんで、Dalvikくんのソースを見るといえば誰がなんと言っても、やっぱりheapでしょう。ということで新しくなったheap.cppを覗いてみました。 dvmCollectGarbageInternal 先ず、余り時間も無く、また明日から出稼ぎお仕事に行かねばならないので、とにかく見たのは、CGInternal
CRubyGCの並列世界 - RubyKaigi2011 - I am Cruby!
rubykaigiえっと、真面目な方の資料はこちら。 CRubyGCの並列世界 View more presentations from authorNari 動画: Ustream.tv: ユーザー rubykaigi: 16S05, 16S05. 会議 書くの忘れていたのですが、ソースコードは以下で公開してます。 authorNari/ruby - GitHub 資料をかなり作り込んで大変だったのだけど、個人的にはたぶん今までで一番いいできのプレゼンというか、かなり自分の理想に近いものになったかなぁ。 まぁ、たぶん聞いてる方はそんなでもなかったでしょうが…。 時間オーバしてごめんなさい。あとのささださんにご迷惑かけてしまいました。ツイートする
徹底解剖「G1GC」 アルゴリズム編
書誌情報 著者: 中村成洋 発行日: 2011-06-27 最終更新日: 2012-02-03 バージョン: 1.0.0 ページ数: 62ページ(A4PDF版換算) 対応フォーマット: EPUB, PDF 出版社: 達人出版会 対象読者 高度なGCのアルゴリズムに興味のある方。すでに『ガベージコレクションのアルゴリズムと実装』を読まれていて、続きを読みたい方 著者について 中村成洋 中村成洋（nari）はネットワーク応用通信研究所に勤めているRubyistです。仕事ではRailsを使ってWebアプリケーションを開発しています。高校を卒業してからはアイス工場に2年半いて、それからプログラマに転職しました。 GCに魅了されてしまった人間で、GC歴は4年になります。CRubyのコミッタとして1年に1度のペースでGCの改善に取り組んでいます。去年はCRubyに新しく取り込まれたLazySweepG
TinyGC - Tiny Garbage Collector
Preface TinyGC is an independent implementation of the API of the well-known Boehm-Demers-Weiser Conservative GC ("BDWGC" or "BoehmGC" for short). TinyGC has been initially developed as a part of the JCGO project to be used as a BoehmGC replacement. At present, TinyGC is a standalone project. Download To get the latest TinyGC stable release source code, please visit "Browse files for TinyGC". Targ
throw Life - Dalvik VMのGarbage Collection概要
ちょっと時間ができたので、知り合いのブログを読みあさってました。 すると、安藤恐竜さんとこでこんな翻訳記事を見つけました。 Track memory allocations（日本語超訳） 大半のケースでは、数多くの小さくて短命なオブジェクトが原因でGCが起動される。世代別GCのような場合には、このようなオブジェクトの回収を最適化し、頻繁にGCが起動されることを防ぐことができる。AndroidのGCは、残念ながらそのような最適化を行うことができず、パフォーマンスに影響の多い一連のコードの中で、短命なオブジェクトを作ると、そのままアプリケーションの性能にとって影響が多くなってしまう。 マジっすか？！一応原文もチェック。 Track memory allocations Most of the time, garbage collection occurs because of tons
write barrier - NyaRuRuが地球にいたころ
９ Generational GC (中略) さて、Schemeにおいて、ユーザプログラムがconsやvectorのみを用いる限り、旧→新のポインタは決して生まれない。 Set-car!などの破壊的代入を行なって初めて生じるものである。コンパイラが、破壊的代入の際に必ずGCに知らせる(書き換えられるオブジェクトを GCに教える)ようにすれば、GCが旧→新のポインタ全てを手早く見つけることができる。このように、メモリオブジェクトへの書き込みの際に特別な処理を行なう機構をwrite barrierという（注）。 (中略) １０ Incremental GC (中略) Generational GCと同様に、write barrierが必要になる (ここではmark and sweepを仮定する)。 Write barrierがないと破綻する例を図8に示す。マークフェイズの途中でaが黒になった時
[Ruby] GC mark改善案 - Matzにっき(2010-05-10)
_ [Ruby] GC mark改善案 おひさしぶり。 GC sweep時間はわりと短縮できそうなので(authorNariくんがLazySweepパッチを書いてくれたし)、 このところGC mark時間を短縮するアイディアはないか、考えている。 今のRubyに入れたいので、制約として、 保守的 mark&sweep write barrierを導入しない というものがある。 しばらく前にTwitterで、「いくつかのオブジェクトをまとめて、その単位でマークする」というアイディアを披露してみたが、すぐに三浦さんから「トラバースのコストが減らないから効果ないんじゃない」との指摘が。ちょっと考えてみたら、確かにその通り。かっくり。 まあ、50年間、いろんな人が考えてきたGCで、画期的なアイディアを思いつくのは難しいよね。 まあ、そういう「誰も知らない系」ではなくて、mark時間短縮に効果のあり
.NET TIPS ガベージ・コレクタを明示的に動作させるには？ - C# VB.NET - ＠IT
C++やVisual Basic 6.0の世界でプログラミングしてきた技術者が.NET Frameworkの世界に入ってきてまずおどろくのは、プログラムを実行していると、プロセスが使用するメモリ量がどんどん増えていくことである。「メモリ・リークか！？」と焦ることもあるが、これは正常な動作である。 メモリの解放忘れは典型的なバグの要因であり、メモリ解放を自動化することによって、プログラムの信頼性は向上し、プログラマーの負担も減る。自動的なメモリ解放を行う機構は、ガベージ・コレクタと呼ばれ、解放する行為をガベージ・コレクションと呼ぶ。問題は、ガベージ・コレクションがいつ行われるかであるが、これはメモリが不足してきた場合や、明示的に動作を指示された場合にのみ行われる。つまり、メモリが潤沢に余っている場合には、プロセスの使用するメモリ量が増加するのが正常な動作である。そのままメモリ不足でプログラム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rubyのメモリ使用量を改善するBitmapマーキングGC
Large Object Heap と.NET GC の改善
Ruby 1.9.3 Preview 1がリリース。Lazy Sweep GCにより、GCの停止時間が改善。
English (US)
ヒープサイズを増やしてもガベージコレクションの停止時間を短いままに: Cliff Click博士とのQ&A
