タグ

GCに関するTokyoIncidentsのブックマーク (17)

  • Go言語のGCについて - LINE ENGINEERING

    なぜGo言語はコンパクションを採用していないのか GoogleのRick Hudson氏によるISMM 2018 Keynote “Getting To Go”を参照すると、以下のことがわかります。 2014年の時点では”Read barrier free concurrent copying GC”を計画していた しかし期間的な制約から断念し、CMSに舵を切った(この時期に彼らは、ランタイムをCからGoに書き換える作業も行う必要がありました。Changes to the runtime) TCMallocをベースとしたメモリアロケーターを採用することで、断片化およびアロケーションの速度の問題を解決した Go言語のメモリアロケーションについては、ランタイムのコードのコメントにも詳しく記載されています。 malloc.go This was originally based on tcmal

    Go言語のGCについて - LINE ENGINEERING
  • Orinoco: young generation garbage collection · V8

    Show navigation JavaScript objects in V8 are allocated on a heap managed by V8’s garbage collector. In previous blog posts we have already talked about how we reduce garbage collection pause times (more than once) and memory consumption. In this blog post we introduce the parallel Scavenger, one of the latest features of Orinoco, V8’s mostly concurrent and parallel garbage collector and discuss de

  • Go言語のリアルタイムGC 理論と実践 | POSTD

    (編注:誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「当にGoを使えば実現できるのか? もしできるならどうやって?」 このブログ記事ではGoのガベージコレクタを、どのように機能し(トリコロールアルゴリズム)、なぜ機能し(こんなに短いGCによる一時停止時間の実現)、そして何よりも、それが機能するのかどうか(GCによる

    Go言語のリアルタイムGC 理論と実践 | POSTD
  • GCの話 | κeenのHappy Hacκing Blog

    #関数型なんたら でGCの話を聴いて、SML#のGCの論文を読んで色々感じたのでエントリー。 Snapshot GC まず、湯浅先生のSnapshot GC (解説)。並列、並行、インクリメンタルにGCが出来る。恐らく一番性能が出るとのこと。解説ではmark & sweepだけど私が聴いたのはCopyingだった。 勿論並行にするにはライトバリアが必要なんだけどその辺にまつわる話。並行じゃなくても世代別GCでもライトバリアが必要になるからその辺も頭に入れて聴いてほしい。Copyingはアロケーションが鬼のように速いのが特徴。mallocの感覚でメモリ確保が重いとか思ってると感覚が狂う。なので新たなオブジェクトを作るコストは非常に低い。そこにオブジェクトの変更にはライトバリアが付くとなると、大きくないオブジェクトの場合 オブジェクトを変更するより新たに作った方がコストが低くなる 。一応言って

    GCの話 | κeenのHappy Hacκing Blog
  • http://www.yuasa.kuis.kyoto-u.ac.jp/~yuasa/YuasasSnapshot.pdf

  • Golangの新しいGCアルゴリズム Transaction Oriented Collector(TOC)

    http://golang.org/s/gctoc Goの新しいGCのProposalが出た.まだProposal段階であり具体的な実装はないが簡単にどのようなものであるかをまとめておく. GoのGCはGo1.5において単純なStop The World(STW)からConcurrent Mark & Sweepへと変更され大きな改善があった(詳しくは“GolangのGCを追う”に書いた).先の記事に書いたようにGo1.5におけるGCの改善は主にレイテンシ(最大停止時間)に重きが置かれいた.数値目標として10msが掲げられGo1.6においては大きなヒープサイズ(500GB)においてそれを達成していた. GCの評価項目はレイテンシのみではない.スループットやヒープの使用効率(断片化の対処)なども重要である.Go1.6までのGCではそれらについて大きく言及されていなかった(と思う).例えばスル

  • Jank Busters Part Two: Orinoco · V8

    Show navigation In a previous blog post, we introduced the problem of jank caused by garbage collection interrupting a smooth browsing experience. In this blog post we introduce three optimizations that lay the groundwork for a new garbage collector in V8, codenamed Orinoco. Orinoco is based on the idea that implementing a mostly parallel and concurrent garbage collector without strict generationa

  • 天泣記 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

    天泣記 2015-10-07 (Wed) #1 frozen_string_literal: true の効果
    TokyoIncidents
    TokyoIncidents 2015/10/07
    自分がわかっていないだけかもしれないけど、マイクロベンチマーク感が否めない。この部分が高速化したところで他にボトルネックはないのだろうか?https://twitter.com/kosaki55tea/status/650711739596673024
  • Ruby 2.1: Out-of-Band GC · computer talk by @tmm1

    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

  • ARTのメモリ管理

    Transcript 1. ARTのメモリ管理 2015/04/25 DroidKaigi @haru067 2. 自己紹介 ● Twitterクライアント
 ShootingStarの開発者 @haru067 3. 自己紹介 ● Twitterクライアント
 ShootingStarの開発者 ● 大学院を無事卒業 ● 修論でARTのGCをいじってた ● 今日はその辺で得た知識の話
 (たまには真面目な話を) @haru067 4. 連絡的な ● Android 5.0リリース時点での話です ● とにかく更新が激しい,既に古くなってるかも ● 最近だとコンパクションとか入ったっぽい?
 https://source.android.com/devices/tech/dalvik/
 ● 質問あればリプライとかハッシュタグで ● 発表資料はあとでアップロードします
 (@haru067) 5

    ARTのメモリ管理
  • 日本語訳: Ruby 2.1: Out-of-Band GC — sawanoboly.net

    @azukiwasher さんからRuby2.1のGCについて解説されている記事の日語訳を頂きました。 『WEB+DBRuby 2.1 特集を読んでたら、ガベージコレクション(RGenGC)の説明で参照されてた記事の次の記事がためになったので訳してみた。』 Vol.79ですね。 ソース Ruby 2.1: Out-of-Band GC · computer talk by @tmm1 Ruby 2.1: Out-of-Band GC Ruby 2.1 で GC は以前よりずっとマシになったが、相変わらず "Stop The World" な実装に変わりはない。リクエスト処理中にコレクションが始まると、リクエストへの応答時間に遅延が生じる。遅延を緩和する方法のひとつにリクエストとリクエストの間に GC を走らせる、いわゆる「Out-of-Band」がある。 OOBGC はよく知られた

  • Matzにっき(2008-02-05)::Copy-on-write friendly patch for Ruby 1.9

    << 2008/02/ 1 1. [言語] 「ハッカーと画家」の著者が新しいLisp系言語「Arc」を公開 | エンタープライズ | マイコミジャーナル 2. 「セキュリティ、なめんなよ!」 なめねこも一緒に情報セキュリティ強化宣言 | ネット | マイコミジャーナル 3. 「サイオステクノロジーはグルージェントの未来技術に期待し子会社化」:ITpro 2 1. [Ruby] Nimble Method: Garbage Collection is Why Ruby on Rails is Slow: Patches to Improve Performance 5x; Memory Profiling 2. [言語] LuaJIT roadmap 2008 3. [Ruby] What will Matz do? 4. [Ruby] EURUKO 2008 − European Ruby

  • Feature #8339: Introducing Geneartional Garbage Collection for CRuby/MRI - Ruby master - Ruby Issue Tracking System

    | One day a Rubyist came to Koichi and said, "I understand how to improve | CRuby's performance. We must use a generational garbage collector." Koichi | patiently told the Rubyist the following story: "One day a Rubyist came | to Koichi and said, 'I understand how to improve CRuby's performance..." | [This story is an homage of an introduction in a paper: | "A real-time garbage collector based on

  • Hey Judy, don't make it bad

    AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be

    Hey Judy, don't make it bad
  • CRubyのGC実装で参考にされたScheme処理系:SIOD - GC Advent Calendar - I am Cruby!

    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

  • Pythonのガベージコレクション - atsuoishimoto's diary

    Python Hack-a-thon 2011/2/19 の発表資料 PythonのガベージコレクションView more presentations from atsuoishimoto.

    Pythonのガベージコレクション - atsuoishimoto's diary
  • 「ガベージコレクションのアルゴリズムと実装」という本を書きました。

    gcbook, gcai, GCGCLoverのみなさん、お待たせしました。「ガベージコレクションのアルゴリズムと実装」の情報公開です。 書名:ガベージコレクションのアルゴリズムと実装 著者:中村 成洋/相川 光 監修:竹内 郁雄 ページ数:472ページ 体価格:3,200円 発売開始日:2010年3月17日(水) ※地域・書店によって遅れることがあります ISBN:978-4-7980-2562-9 C3055 読み所 書は次の2つのテーマを扱います。 1.GCのアルゴリズム(アルゴリズム編) 2.GCの実装(実装編) アルゴリズム編では、これまでに考案されてきた数多くのGCアルゴリズムの中 から、重要なものを厳選して紹介します。伝統的かつ基的なものから、やや 高度なアルゴリズムを選定しています。GC独特の考え方や各アルゴリズムの特 性などを理解していただくのがアルゴリズム編の最大

  • 1