WebAssemblyのガベージコレクションが正式機能に、最新版のChrome 119で。Firefoxも今月リリースのFirefox 120で正式機能になる見通し
WebAssemblyのガベージコレクションが正式機能に、最新版のChrome 119で。Firefoxも今月リリースのFirefox 120で正式機能になる見通し 2023年2月にリリースされたChrome 111から試験的実装となっていたChromeにおけるWebAssemblyのガベージコレクション機能（以下、WasmGC）が、10月31日にリリースされたChrome 119で正式機能になったことが明らかになりました。 Firefoxでも今月（2023年11月）21日リリース予定のFirefox 120においてWasmGCが正式機能になる見通しです。 WasmGCを利用することで、ガベージコレクション機能が言語のランタイムに含まれているJavaなどプログラミング言語をWebAssemblyで実装することが容易になるため、今後WebAssembly上でさまざまなプログラミング言語の実装
「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読んだ
最近「おれってガベージコレクションを勉強するにあたってめちゃくちゃ恵まれた環境にあるのでは？」とふと思い立ち、ベージコレクションの勉強を始めました。 ガベージコレクションの勉強を始めるにあたって、とりあえず「The Garbage Collection Handbook (first edition)」の邦訳である「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読むことにしました。 この記事では、読み終わってうれしいので、雑に感想を書きなぐっています。表記が「GC」だったり「ガベージコレクション」だったりするのは雑に書いたからです。 前提知識 ガベージコレクションの事前知識はほとんど不要で、何をしてくれるものか大まかにわかっていれば良い程度だと思います。つまり、ヒープに確保した領域を明示的に解放しなくても、何かのアルゴリズムでいい感じにやってくれる仕組み、ということを知って
Go製ミドルウェアのメモリリークを解決した話 - Mirrativ Tech Blog
インフラ・ストリーミングチームの id:udzura （@udzura）です。今回は、Goミドルウェアのメモリリークを見つけて解決する際に、どのようなプロセスを踏んでいったかを解説します。 Go製のミドルウェアの概要 ミラティブでは、Webアプリケーションのみならず、ミドルウェアに相当する部分についても必要なものは内製しています。その中の一つに、社内で「Radisha」と呼んでいる各種集計とキャッシュなどを行うためのミドルウェアがあります。Radishaは以下のような特徴を備えています。 GET、SET、SETEXなど基本的なRedis互換のコマンドを実装している。そのため、既存のRedisクライアントライブラリから操作が可能である。 ランキング集計、一定時間内のアクセス集計などが行えるよう、Redis にない独自のコマンドを実装している。 高い可用性を志向しており、オンメモリのデータは
GoはいつGCするのか?
TL;DR Go(のランタイム)は以下のタイミングで自動的にGCを実行する 前回のGC後に占有していたメモリと同量を新たに確保したとき 前回のGCから2分後 cgroupなどでメモリ制限しているときは、メモリ使用量が制限の50%以上になったらruntime.GC()を呼び手動でGCすべきである 前置き: GoとOOMのこれまで 以下はGo 1.16での調査結果です。Goのバージョンが異なった場合は事情が異なる可能性があります。 Goでプログラムを書く際に、使用メモリ量を気にしなければならないシーンはGCのおかげでそう多くはありません。実際それは間違いではないのですが、運用まで視野に入れるとそうは言ってられないことがあるのもまた現実です。昨今はコンテナの利用が当たり前になったことに伴い、OOMによりプロセスが強制的に終了させられることもあり、それを避けるために一定量以下のメモリで動くことが重
オブジェクトライフサイクルとメモリ管理を学ぼう / OOC 2020
Object-Oriented Conference 2020 https://ooc.dev/ #ooc_2020 #ooc_b Session Abstract https://fortee.jp/object-oriented-conference-2020/proposal/a07d…
JVM入門 -メモリ管理編-
関ジャバ'19 7月度 - connpass https://kanjava.connpass.com/event/134133/ 登壇資料
Go GC : LINE Engineering Blog
Compaction Garbage collection can either be non-moving or moving. Non-moving GC Non-moving garbage collectors do not relocate objects in a heap. CMS, the collector Go uses, is non-moving. Generally, if you repeat memory allocation and deallocation in non-moving garbage collection, you end up with heap fragmentation, and thus lessened performance for allocation. But, of course, this will depend on
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
How JavaScript works: memory management + how to handle 4 common memory leaks
A few weeks ago we started a series aimed at digging deeper into JavaScript and how it actually works: we thought that by knowing the building blocks of JavaScript and how they come to play together you’ll be able to write better code and apps. The first post of the series focused on providing an overview of the engine, the runtime, and the call stack. Thе second post examined closely the internal
Go言語のリアルタイムGC 理論と実践 | POSTD
(編注：誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「本当にGoを使えば実現できるのか？ もしできるならどうやって？」 このブログ記事ではGoのガベージコレクタを、どのように機能し（トリコロールアルゴリズム）、なぜ機能し（こんなに短いGCによる一時停止時間の実現）、そして何よりも、それが機能するのかどうか（GCによる
「障害に捨てるところなし」というお話をしました - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！アプリケーション基盤チームの@yokotasoです。 3月11日にBattle Conference U30 というイベントでお話をさせていただきました。 準備がてら作成したディスクリプションを公開します。 キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。 では、どうぞ！ 障害にすてるところなし サイボウズ株式会社の横田です。 「障害に捨てるところなし」というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。 運用障害の話 まずはじめに、今回のお話をするにあたりまして 運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。 より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。 これからも、弊社製品をよろしくお願いいたします。 クラウドの規模と稼働率 障害の話をする前に、サイボウズの
JavaScriptのメモリ消費について
今回は、メモ書き... テーマはJavaScriptのメモリ消費についてです。 JavaScriptのメモリモデルはガベージコレクションという技術を用いています。 この手法は、ガベージコレクター(以下、GC)が最適と判断したタイミングでメモリの開放を行います。 問題点としては、下記があげられます。 ・タイミングが制御できない ・GCの処理中は、プログラムが利用可能な処理時間を奪う 要は、メモリ消費が大きいWebアプリはGCが頻発し、パフォーマンス劣化に繋がるよってこと。 GCの頻度はどうやって確認する？ 下記の画像は、YahooのトップページをDeveloper ToolsのTimelineタブでレコーディングしたものです。 山になっている水色部分がメモリの使用量で、一回ガクッと下がっています。 これがGCのタイミングで、ギザギザになってるほどGCの頻度が高いです。 （「バージョン 39.
java.lang.OutOfMemoryError: GC overhead limit exceeded - Develop with pleasure!
Javaなエンジニアであればお馴染みのOutOfMemoryError。 こないだ単体テストを全件流してたら途中で java.lang.OutOfMemoryError: GC overhead limit exceeded が発生。お馴染みのOutOfMemoryErrorかと思ったけどメッセージに「GC overhead limit exceeded」とある。 いつもの「Java heap space」とかいうメッセージじゃないので気になって調べてみる。 この「GC overhead limit exceeded 」は、HotSpot VMの1.6からデフォルトで有効になったポリシーで、ヒープ領域が不足する前に早期に潜在的なOutOfMemoryErrorの検出するために導入された模様。このポリシーはGCの経過時間と頻度が基準になってて、経過時間が長かったり頻繁にFull GCが発生す
Node 学園祭 2016 個人的なまとめ - Qiita
Node 学園祭 2016 印象に残ったセッションのまとめ。 計画・実施されたみなさま、とても楽しかったです。ありがとうございました !! 動画も公開されたようです。 Demystifying JavaScript Engines http://slides.com/a0viedo/demystifying-js-engines#/ https://github.com/a0viedo/demystifying-js-engines http://togetter.com/li/1047918 JavaScript エンジンについてのセッション。 2006 年ごろの牧歌的なインタープリターのハナシからはじまって、 JIT のかけ方、各実装ごとの最適化のかけかた、 Garbage Collection の実装まとめまで。 最後の話題である GC について↓あたり読めばいいかも。 http:/
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ではそれらについて大きく言及されていなかった（と思う）．例えばスル
Node.jsでのJavaScriptメモリリークを発見するための簡単ガイド | POSTD
目次 初めに 極小理論 ステップ1. 問題の再現と確認 ステップ2. 最低3回のヒートダンプ採取 ステップ3. 問題の発見 ステップ4. 問題解決の確認 他のリソースへのリンク まとめ Something you might want to bookmark: Simple Guide to Finding a JavaScript Memory Leak in Node.js by @akras14 https://t.co/oRyQboa8Uw — Node.js (@nodejs) January 6, 2016 注釈：お気に入りに登録してください。 Simple Guide to Finding a JavaScript Memory Leak in Node.js （Node.jsでのJavaScriptメモリリーク発見簡単ガイド） @akras14 http://www.ale
GolangのGCを追う
Go1.5とGo1.6でGoのGCのレイテンシが大きく改善された．この変更について「ちゃんと」理解するため，アルゴリズムレベルでGoのGCについて追ってみた． まずGoのGCの現状をパフォーマンス（レイテンシ）の観点からまとめる．次に具体的なアルゴリズムについて，そして最後に実際の現場でのチューニングはどうすれば良いのかについて解説する． GoのGCの今 最初にGoのGCの最近の流れ（2016年5月まで）をまとめる． Go1.4までは単純なStop The World（STW）GCが実装されていたがGo1.5からは新たなGCアルゴリズムが導入された．導入の際に設定された数値目標は大きなヒープサイズにおいてもレイテンシを10ms以下に抑えることであった．Go1.5で新たなアルゴリムが実装されGo1.6で最適化が行われた． 以下は公開されているベンチマーク．まずはGo1.5を見る． Gophe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GoのGC (garbage collector)について理解する
Go GC visualized
go gc algorithm 101
