Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? gc(garbage collection)とは 確保したメモリを自動的に解放してくれる仕組み メモリを確保する際は、アプリケーションが要求した量より多い量が確保される。その多い分は、要求したメモリの管理のためで、管理領域があることで要求したメモリが辿れるようになっている。アプリケーションが要求した領域を解放する際は、管理領域を使って、順次メモリを辿っていき、合致する領域を探すといった事を行う。 mark & sweep 古典的なgcの一つにmark & sweepがある mark & sweepでは、使っていないメモリを探して解放する
技術部の鈴木 (@eagletmt) です。 先日、クックパッドで使われている Ruby のバージョンを 2.0.0 から 2.2 にアップグレードしました。 アップグレードは主に @sorah と私で進めました。 今回はアップグレードまでの過程やアップグレード当日の流れ、そして今のところ見られているアップグレードによる効果などについて紹介します。 アップグレードまでの準備 テストを通す Ruby 2.1 がリリースされたときから 2.1 にアップグレードできないか検証環境でテストを回していました。 しかし、当時はクックパッドの全テストを実行すると必ず途中で Ruby がクラッシュする現象に悩まされていました。 Ruby の GC のバグ、拡張ライブラリのバグを疑いながら色々やってみたものの結局解決できず、Ruby 2.2 がリリースされてからもこの状況は改善されませんでした。 しかしある
pwd が何の略か？ ということを聞かれた。確かに答えられない。 http://www.abbreviations.com/pwd の中で working directory を含むものをピックアップすると、 Print Working Directory Present Working Directory Path of Working Directory の３説が見つかる。 man を見ても、あんまりしっくりこない。なんで cwd （current working directory）にしなかったんだろう？ system call は getcwd(2) なのに。 昨日の続き。 早速中田さんが r49614 を入れてくれて、こういう a, b = x, y の時には、 push x # stack: x push y # stack: x y newarray 2 # stack: [
Rebuild: 53: Less Code Is Better Code (Matz) rebuildfm 53のRubyのGCとスレッドの話が面白かったので書いてみる。 RubyのGCというとクックパッドがユーザのリクエスト中にGCを止めるっていう話があったぐらいなので改善が望まれる分野なんだと思います。 例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life Rubyは2.1になって世代別GCが導入されるようになりました。その辺は下記に詳しいです。 WEB+DB PRESS Vol.79 作者: 成瀬ゆい,そらは(福森匠大),西磨翁,小川航佑,佐藤新悟,塚越啓介,藤原亮,堀哲也,田村孝文,桑野章弘,松浦隼人,中村俊之,田中哲,福永亘,杉山仁則,伊藤直也,登尾徳誠,近藤宇智朗,若原祥正,松木雅幸,奥野幹也,後藤秀宣,羽二生厚美,笹田耕一,平河正博,東舘智
29 Jan 2014 Ruby 2.1's GC is better than ever, but ruby still uses a stop-the-world GC implementation. This means collections triggered during request processing will add latency to your response time. One way to mitigate this is by running GC in-between requests, i.e. "Out-of-Band". OOBGC is a popular technique, first introduced by Unicorn and later integrated into Passenger. Traditionally, these
http://samsaffron.com/archive/2013/11/22/demystifying-the-ruby-gc Ruby 2.1のガベージコレクタ (GC) については、「RubyとPythonの違いからガベージコレクタを理解する [その1] [その2] 」で取り上げましたが、今回は、DiscourseのSam SaffronがまとめているRuby 2.0のGCを利用するにあたっての学びを紹介します。 1) Heaps of heaps MRIはヒープにRVALUEとして知られているオブジェクトをもつ。各ヒープは約16KB。RVALUE構造体は、マシンのアーキテクチャによって異なる量のメモリを消費する。x64マシンでは40 byte、x32マシンではサブアーキテクチャー次第で20 byteから24 byte。RVALUEはマジカルなC構造体で、Rubyの様々なローレベル
http://patshaughnessy.net/2013/10/30/generational-gc-in-python-and-ruby 前回のエントリーはこちら。 ブタペストで開催されたRUPY2013でのPat Shaughnessyのプレゼンの後半です。RubyとPythonのガベージコレクタの違いを、今回は、Pythonの循環データ構造への対応とRuby 2.1の世代別ガベージコレクタの話題に触れながら、紹介しています。 1) Pythonの循環データ構造と参照カウント Pythonは、いくつのポインタがそのオブジェクトを参照しているかを、参照カウントと呼ばれる整数で管理している。変数もしくはオブジェクトが、そのオブジェクトを参照しはじめれば数字が増えて、プログラムがそのオブジェクトを使うのをやめれば数字が減る仕組み。 1960年代以来、コンピュータ科学者が気づいているアルゴ
http://patshaughnessy.net/2013/10/24/visualizing-garbage-collection-in-ruby-and-python Pat Shaughnessyが、ブタペストで開催されたRUPY2013でのプレゼンの前半を自らのブログで紹介しています。 ガベージコレクタは、「ゴミを集める」という行為だけでなく、「新しいオブジェクトのためにメモリをあてがう。」「不要なオブジェクトを見つける」「不要なオブジェクトからメモリを取り戻す。」という、人間の心臓が血液を浄化するような働きをしている。 この簡単なコードサンプルを見ると、RubyとPythonの記述はよく似ているが、それぞれの言語の内部でのインプリの仕組みは違う。 1) Rubyのメモリ Rubyは、コードが実行される前に、数千のオブジェクトを先につくり、それをリンクされたfree listに置
2019-03-28 Python/インスタンス生成 2018-01-02 Python/クロージャ Pythonを読む 2018-01-01 Python/メソッド呼び出し 2017-12-31 Python/build_class後編 2017-12-30 Python/読解対象とするPythonコードと解析方法 2017-12-24 Python/build_class前編（というよりPyTypeObject） 2017-12-07 Python/ビルトインがビルトインされるまで 2017-12-03 Python/C関数実行とPyObject 2017-10-22 Django/テンプレートシステムを読む（レンダリング） Djangoを読む 2017-10-21 Django/テンプレートシステムを読む（テンプレートのパース） 2017-09-24 Django/テンプレートシステ
mrubyのGCの仕組みを調べた - ブレ男のブログ
2013年4月18日木曜日 mrubyのGCの仕組みを調べた 時刻: 0:09 動機 LuaのAPIは、Lua内部で扱われる値に関してスタック上であれこれ操作出来るだけで、値自体を直接取得したり作成することはできない。値を取り出したいときはスタック上のある場所にある値の型を調べて、その型の値を取り出すAPIを呼び出す、という具合になっている。この場合、処理系で扱う値はすべて処理系側で管理されているので、ガベージコレクト(GC)できるのもわからんでもない。 しかしmrubyのAPIではスクリプト内部で扱う値をmrb_valueとしてC言語側に直接取り出せる。この場合処理系の管理を逃れてしまうことはないのか。またCの関数でmrubyのオブジェクトを作成した瞬間にGCが走った場合に、まだmrubyで管理している変数からの参照がなくて、解放されてしまったりしないのか。 大昔の事しか知らないけど
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
Garbage Collection Advent Calendarの25日目の記事です。 ついに、か、完走したぞ！！うぉぉー。はあ、つかれた。もう来年はいいです。 ということで今日の分のスライドもあわせて、まとめてこの記事にはりつけておきます。 （あーあ、はてなダイアリーにslideboom埋め込めないのか…） mrubyのTri-color incremental mark & sweep GC 解説 その1 mrubyのTri-color incremental mark & sweep GC その2 mrubyのTri-color incremental mark & sweep GC その3 しかし、スライドのアニメーションとGCの解説って相性いいですねえ。 Impressでpptを吐いているのですが、それなりにslideboom上でも動いてびっくりしています。ツイートする
Garbage Collection Advent Calendarの8日目(!!)の記事です。 gc.cの最初のほうのコミットを見るとCOPYRIGHTがあって、SIOD:Scheme In One Defunという処理系を参考にまつもとさんはCRubyのGCを実装されたみたいなんですね。 /gc.c - ruby-trunk - Ruby Issue Tracking System この当時はスッキリしたソースコードですね。 SIOD - Wikipedia, the free encyclopedia SIOD: Scheme in One Defun SIODは公式サイトなどを読むと1988年にリリースされ、最後のリリースが2007年、と。 30年も続いてんのかあ。 で、wikipediaには以下のように書かれていますね。Scheme In One Defun (or Scheme
GCそういえばBitmapMarking GCについて@m_stさんにInfoQで質問をうけました。 だいぶん残念な英語を返したのですが、向こうのインタビュイーさんの方でいろいろ修正していただいたみたいです。感謝感謝。 で、ちと意訳ですが以下に日本語訳も書いておきます。 ちょっとだけ補足したいこともあったので。 InfoQ Japanの方でも日本語訳していただいてます。ありがとうございます。 CGの話も追加してもらったみたいですね。 RubyのBitmap Marking GCによるメモリ使用量の改善原文 Narihiro Nakamuraによって書かれたGCの最大停止時間を短くするLazy Sweep Garbage Collector(参照:InfoQによるレポート) が、Ruby1.9.3には導入されている。 最近、Narihiroはcopy-on-wirte(CoW) friend
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
