Garbage Collection in Ruby - Peter Zhu
Overview Ruby’s garbage collector code lives in a single file called gc.c. “Garbage collector” is probably not the best term to call it because in addition to garbage collection, the code inside gc.c is responsible for memory allocation and management. In other words, the whole lifecycle of an object is managed by the garbage collector. Primitive object types While every type of Ruby object may ap
CRuby のメモリ管理を MMTk で再構築する試み（翻訳）｜TechRacho by BPS株式会社
原注 本記事は、私たちの論文『Reworking Memory Management in CRuby: A Practitioner Report』および「International Symposium on Memory Management 2025」の以下の講演を元にしています。 論文はこちらで開けます。 最初に、このプロジェクトにおいてオーストラリア国立大学との共同研究のきっかけを作ってくださった故Chris Seaton氏と、彼の貢献、先見性、そしてリーダーシップに心より感謝いたします。彼がいなければ、このプロジェクトは実現しなかったでしょう。 🔗 背景 オーストラリア国立大学（ANU）とShopifyは、メモリ管理ツールキット（Memory Management Toolkit: MMTk）をRubyに統合するプロジェクトで協力しています。私たちはこのプロジェクトを支援し、
New for Ruby 3.4: Modular Garbage Collection and MMTk
Introduction Ruby garbage collection has always been a frequently discussed topic in the community. With recommendations on tuning strategies for better performance, and even entire sets of patches designed to optimize it, going back at least as far as 2008 and Ruby 1.8. I spoke at RubyKaigi in 2023 about the history of the Ruby garbage collector, and its evolution since the origins of the languag
Ruby 3.4に導入される次世代の帯域外ガベージコレクション（翻訳）｜TechRacho by BPS株式会社
概要 CC BY-NC-SA 4.0に基づいて翻訳・公開いたします。 英語記事: Next Generation Out of Band Garbage Collection | Rails at Scale 原文公開日: 2024/10/23 原著者: Jean Boussier 日本語タイトルは内容に即したものにしました。 CC BY-NC-SA 4.0| 表示 - 非営利 - 継承 4.0 国際 | Creative Commons 私は2023年に、RubyのガベージコレクタをShopifyのモノリス向けにチューニングしたときの方法について以下の記事を書きました。この記事では、メジャーガベージコレクション1によるレイテンシへの影響を軽減するために帯域外ガベージコレクションを実装する方法についても触れました。 参考: Adventures in Garbage Collection:
Gradual Write-Barrier Insertion into a Ruby Interpreter
Gradual Write-Barrier Insertion into a Ruby Interpreter Koichi Sasada Cookpad Inc. Japan ko1@cookpad.com Abstract Ruby is a popular object-oriented programming language, and the performance of the Ruby garbage collector (GC) di- rectly affects the execution time of Ruby programs. Ruby 2.0 and earlier versions employed an inefficient non-generational conservative mark-and-sweep GC. To improve this
Two Garbage Collection Improvements Made Our Storefronts 8% Faster
At Shopify, we are constantly working on improving the performance of Ruby for everyone. From YJIT, to Variable Width Allocation, to Object Shapes, we are making improvements to Ruby in many areas. One of our goals for the year is to analyze, tune and improve Ruby’s garbage collector for our largest and highest traffic apps. One of these apps is Storefront Renderer, which serves the storefronts of
Adventures in Garbage Collection: Improving GC Performance in our Massive Monolith - Shopify
Adventures in Garbage Collection: Improving GC Performance in our Massive MonolithAt the beginning of this year, we ran several experiments aimed at reducing the latency impact of the Ruby garbage collector (GC) in Shopify's monolith. In this article, Jean talks about the changes we made to improve GC performance, and more importantly, how we got to these changes. At the beginning of this year, we
Ruby Garbage Collection Deep Dive: Compaction
So far in this series, we’ve discussed GC::INTERNAL_CONSTANTS, the Tri-Color Mark and Sweep algorithm, Generational GC and Incremental GC. We’ll build on what we’ve learned in this post about the newest addition to Ruby’s GC: compaction. Fragmentation Before we dive into compaction, we need to learn about fragmentation. Fragmentation is the term we use to describe memory when it’s allocated non-co
ISMM 2019 で発表してきました - クックパッド開発者ブログ
技術部の笹田です。遠藤さんと同じく Ruby のフルタイムコミッタとして、Ruby インタプリタの開発だけをしています。 先日、アメリカのフェニックスで開催された ISMM 2019 という会議で発表してきたのと、同時開催の PLDI 2019 という会議についでに参加してきたので、簡単にご報告します。 カンファレンス会場 ISMM 2019 ISMM は、International Symposium on Memory Management の略で、メモリ管理を専門にした、世界最高の学術会議です。というと凄いカッコイイんですが、メモリ管理専門って凄くニッチすぎて、他にないってだけですね。多分。ACM（アメリカのコンピュータ関係の学会。すごい大きい）SIGPLAN（プログラミングに関する分科会。Special Interest Group）のシンポジウムになります。 発表するためには、他
Rubyコミッター・笹田耕一に世代別インクリメンタルGCを発想したプロセスを聞いてみた - エンジニアHub｜Webエンジニアのキャリアを考える！
Rubyコミッター・笹田耕一に世代別インクリメンタルGCを発想したプロセスを聞いてみた Rubyのフルタイムコミッターである笹田耕一さんに、Rubyの処理性能を向上させるいくつかのブレイクスルーをどのように解決し、どのような困難があったのかを聞きました。 直感的な文法や生産性の高さから、世界中の人々に愛されるオブジェクト指向スクリプト言語Ruby。その黎明期から現在に至るまで、大きな変化を遂げてきた要素があります。“処理速度”です。数々の最適化が行われた結果、Rubyの処理性能はかつてとは比べものにならないほど向上しました。 その改善を支えたのは、世界中のRubyコミッターたち。中でも、性能向上において多くの成果を残してきたのが、クックパッド株式会社でフルタイムRubyコミッターとして働く笹田耕一（ささだ・こういち／ @koichisasada ）さんです。本稿では、彼がいかなる設計方針に
Introduce 2nd GC heap named Transient heap
Abstract¶ We propose to introduce "2nd" GC managed heap named "Transient heap" into MRI, instead of malloc management heap. Employied GC algorithm is similar to "generational" "copying" GC algorithm. This technique can reduce problems of malloc'ed heap. Background¶ MRI and malloc¶ MRI manages memory by GC managed heap and malloc'ed heap. Objects are allocated from GC managed heap. However, each ob
Ruby の NODE を GC から卒業させた - クックパッド開発者ブログ
こんにちは、技術部のフルタイム Ruby コミッタの遠藤（@mametter）です。メリークリスマス。 本日 Ruby 2.5.0 がリリース予定です。いろいろな改善が含まれています。クックパッドからの主な貢献としては、「trace 命令の削除による高速化」や「分岐・メソッドカバレッジの測定のサポート」などがあります。 ユーザから見える改善はいろいろと記事が出てくると思うので、この記事では、「抽象構文木のメモリ管理のリファクタリング」というあまりユーザから見えない改善を紹介してみます。 概要 Ruby のパーサは、NODE という内部的なオブジェクトで構成された抽象構文木を生成します。2.4 までの NODE は GC に管理される普通のオブジェクトでしたが、2.5 からは GC の外で管理するようになりました。これにより、3 つ嬉しいことがあります。 大きなコードのパースが速くなりました
RubyのGCと仲良くしたい〜WeakRefオブジェクトを削除するぞ編〜 - Qiita
Rubyでは、作成したオブジェクトがなにかのタイミングでGCによってメモリから解放されています。 一般的なオブジェクトは、どこからかに参照されている間は必要、参照されていないなら不要とGCに判断され、メモリから解放されます。 例外的に 弱い参照 -Wikipedia として定義されたオブジェクトは、まだ参照されていてもなにかのタイミングでGCにぽいぽいされてしまいます。 一見、使いようが無いようですが、生成コストがかかる値をキャッシュしておき、メモリに余裕がない場合（一般にGCが動くタイミング）にキャッシュを破棄する、というようなことができます。 機能の実現に必要となることはありませんが、速度改善などに役立つテクニック的な。 なおタイトルはてきとーです。「○○編」と書いていますが、別の編があったりはしません。たぶん。 Ruby2.1で動作検証をしましたが、1.9以降ならたぶん大丈夫なんじゃ
雑なツイートをしてしまったばかりにrubyを高速化するはめになった俺たちは！
逆に言うと、Rubyの文字列型の内部実装がropeになれば、freezeしてもしなくても変わらない速度が出るようになって、結局freezeする必要なんてなかったんやーで丸く収まるんじゃないの？と思いました #雑な感想 — Kazuho Oku (@kazuho) October 6, 2015とツイートしたところ、処理系の中の人から @kazuho 文字列を弄る話じゃなくて、文字列の identity の話なので、ちょっと関係ないかなぁ、と — _ko1 (@_ko1) October 6, 2015みたいなツッコミをもらって、うっすみません…ってなってRuby VMのコードを読むことになったわけです。 で、まあ、いくつか気になる点があったので手をつけてしまいました。 1. オブジェクト生成のホットパスの最適化 ホットスポットだとされていたところのコードを読んでると、オブジェクト生成の際に
天泣記 2015-10-07 (Wed) #1 frozen_string_literal: true の効果
2015-10-07 (Wed)#1 frozen_string_literal: true の効果えんどうさんの「Ruby 3.0 の特大の非互換について」が話題になっているので定量的な話と社会問題について述べてみよう。 文字列リテラルの評価において文字列オブジェクト生成を抑制することで本当に速くなるのか、というのは興味のあるところである。ぜんぜん速くならないなら、.freeze をつけるようなリクエストはぜんぶ拒否してしまえばいいわけで、社会問題などという話にはならない。 ささださんの計測によれば、文字列オブジェクト生成に対して、GC のコストは少ないそうである。とはいえ、文字列オブジェクトを生成しなければ、生成コストと GC コストを除去できるので、それが積み上がって実際のアプリケーションがどの程度速くなるのか、というのが問題である。(GC コストについては、除去されるというより、G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Speed ISeq marking by using a bitmap and rearranging inline caches by tenderlove · Pull Request #6053 · ruby/ruby
Ruby Garbage Collection Deep Dive: GC::INTERNAL_CONSTANTS
https://jemma.dev/blog/gc-mark-and-sweep
Methods of Memory Management in MRI
Ruby 2.4.0 アップグレード後のメモリ状況 - koicの日記
