Garbage collection and closures
Me, Surma, and Jason were hacking on a thing, and discovered that garbage collection within a function doesn't quite work how we expected. function demo() { const bigArrayBuffer = new ArrayBuffer(100_000_000); const id = setTimeout(() => { console.log(bigArrayBuffer.byteLength); }, 1000); return () => clearTimeout(id); } globalThis.cancelDemo = demo(); With the above, bigArrayBuffer is leaked fore
Chromium Docs - The Rule Of 2
When you write code to parse, evaluate, or otherwise handle untrustworthy inputs from the Internet — which is almost everything we do in a web browser! — we like to follow a simple rule to make sure it's safe enough to do so. The Rule Of 2 is: Pick no more than 2 of untrustworthy inputs;unsafe implementation language; andhigh privilege. (drawing source here) Why?When code that handles untrustworth
[Zig] Arena Allocatorを使った "ふつうの" Zigプログラミング
タイトルは、『ふつうのHaskellプログラミング』にちなんでみた。一見難しく感じるZigが、Pythonなどのように"ふつうに"使えると感じるきっかけにこの記事がなると嬉しい。 （記事自体の難易度もふつうにしたかったのだけれど、自分の技量不足で専門用語が多くなってしまったので、今後加筆して簡単にいきたい。） 自分がZigを書き始めようと思った理由はいくつかあるのだけれど、一番大きな理由は「Arena Allocator（アリーナ・アロケーター）」を理解したことが大きかった。 Zigなどのメモリを自分で管理しなければならない言語というのは、開発コストが大きい、と自然に感じてしまう。自分もZigに以前から魅力を感じていたけれど、それがネックで長い間敬遠していた。 ちなみにArena Allocatorを自分が知ったきっかけは実はZigではなく、EmberGenという有名なリアルタイムシミュレ
![[Zig] Arena Allocatorを使った "ふつうの" Zigプログラミング](https://cdn-ak-scissors.b.st-hatena.com/image/square/1db67149ed7f3a13eca490ba38ecb5989dc36193/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--V0VkWwu0--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BZig%25255D%252520Arena%252520Allocator%2525E3%252582%252592%2525E4%2525BD%2525BF%2525E3%252581%2525A3%2525E3%252581%25259F%252520%252522%2525E3%252581%2525B5%2525E3%252581%2525A4%2525E3%252581%252586%2525E3%252581%2525AE%252522%252520Zig%2525E3%252583%252597%2525E3%252583%2525AD%2525E3%252582%2525B0%2525E3%252583%2525A9%2525E3%252583%25259F%2525E3%252583%2525B3%2525E3%252582%2525B0%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Afunatsufumiya%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzYzMjEzNTRlN2EuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
スタディサプリ最大のRailsアプリケーションにYJIT+pitchforkを導入してメモリ使用量を劇的に削減するまで - スタディサプリ Product Team Blog
こんにちは。SREのkyontanです。Rubyが大好きなのでRubyの話をします。ちなみにリクルートはRubyKaigi 2024へGold Sponsorとして協賛しています! *1。ぜひ沖縄でお会いしましょう。 これはあるアプリケーションのメモリ消費量を示すグラフなのですが、まさかgemを入れ替えるだけでこんなに嬉しい変化が見られるとは思っていませんでした。今日はそんなgemの話をします。 話は遡って2023年4月のある日、インターネットを眺めていたところ、ShopifyがpitchforkというOSSを公開したという情報が目に留まりました。 調べてみると、どうやら著名なRackサーバー実装の1つであるunicornの派生版であり、メモリ使用量の削減に特化しているらしいのです。 github.com これはスタディサプリ小中高のあのリソースドカ食いマイクロサービス第一位である api
JavaScript 実行エンジンの V8 を学ぶ | 株式会社CAM
｜はじめに こちらはCAM advent calendar 2022の14日目の記事です。 こんにちは、普段CAMでバックエンドの開発をしている吉瀬です。 Node.js デザインパターンという本を読み Node.js のアーキテクチャについて学んでいます。 その中でも今回は JavaScript 実行エンジンの一つである V8について紹介します。 出典(https://www.oreilly.co.jp/books/9784873118734/) ｜おことわり ・Parse と Compileの詳細な話はしません ・WebAssembly の話はしないので Liftoff の話はしません ・ブラウザ側の話はしません ・できる限り一次情報を参照するようにしていますが、誤っている箇所がある可能性があります ｜V8 とは V8 とは JavaScript 実行エンジンの一つで Google が
ちょっとだけ Inside node.js - KrdLab's blog
またしてもスケジュールきつめのプロジェクトに放り込まれた KrdLab です．Java ジャバしてます．IDE がないとコード書くのがしんどすぎて，もううんざりです． はじめに 何らかのプラットフォームを利用する場合，その仕組みについて知っておくことは，より適切な設計を行うという目的に対して有用な情報となるでしょう． というわけで，今回は少しだけ node.js の内部に潜ってみようと思います．対象は git repo から clone した 0.4.x です (2011/03/29 に clone したっぽい)． なお，今回はイベント駆動に焦点を当て，V8 については割愛します． 見出し 全体像 メイン処理 イベントループで処理される各種 watcher tick 系のイベント処理 gc 系のイベント処理 eio 系のイベント処理 IOWatcher によるソケットの READ/WRIT
ヒープ スナップショットを記録する | Chrome DevTools | Chrome for Developers
概要ビュー 最初に、ヒープ スナップショットが [Summary] ビューで、1 つの列に Constructors とリスト表示されます。コンストラクタを展開して、それがインスタンス化されたオブジェクトを表示できます。 無関係なコンストラクタを除外するには、[Summary] ビューの上部にある [Class filter] に、検査する名前を入力します。 コンストラクタ名の横の数字は、そのコンストラクタで作成されたオブジェクトの総数を示します。[概要] ビューには、次の列も表示されます。 距離は、ノードの最短単純パスを使用したルートまでの距離を示します。 Shallow size: 特定のコンストラクタで作成されたすべてのオブジェクトの浅いサイズの合計を示します。シャローサイズとは、オブジェクト自体が保持するメモリのサイズです。一般的に、配列と文字列は浅いサイズです。オブジェクトのサイ
「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読んだ
最近「おれってガベージコレクションを勉強するにあたってめちゃくちゃ恵まれた環境にあるのでは？」とふと思い立ち、ベージコレクションの勉強を始めました。 ガベージコレクションの勉強を始めるにあたって、とりあえず「The Garbage Collection Handbook (first edition)」の邦訳である「ガベージコレクション 自動的メモリ管理を構成する理論と実装」を読むことにしました。 この記事では、読み終わってうれしいので、雑に感想を書きなぐっています。表記が「GC」だったり「ガベージコレクション」だったりするのは雑に書いたからです。 前提知識 ガベージコレクションの事前知識はほとんど不要で、何をしてくれるものか大まかにわかっていれば良い程度だと思います。つまり、ヒープに確保した領域を明示的に解放しなくても、何かのアルゴリズムでいい感じにやってくれる仕組み、ということを知って
そのテスト、最後まで実行されていますか？ jestとnpm-run-allの恐るべき罠
皆さんこんにちは。この記事では、筆者が最近業務中に経験した恐るべき罠についてシェアしたいと思います。 CIでユニットテストを実行することは、とても多くのプロジェクトで行われています。ユニットテストは特に、既存のコードの変更を自信を持って行うために必要なものです。弊社でも、CI (GitHub Actions) でユニットテストを実行しています。 あるとき、CIの挙動が不安定になったことをきっかけに、CI上でのユニットテストの実行について調べてみました。その結果、とんでもないことが判明したのです。 不安定になったCI 時折、CIにすごく時間がかかり、30分経ったあたりでタイムアウトしてしまうことがありました。そのときのログを見てみると、jestによるユニットテストが実行されている最中に、何のログも出力せずに突然止まっているようでした。そのようなときはリトライするとそこそこの確率で成功します。
Improving Firefox stability with this one weird trick – Mozilla Hacks - the Web developer blog
The first computer I owned shipped with 128 KiB of RAM and to this day I’m still jarred by the idea that applications can run out of memory given that even 15-year-old machines often shipped with 4 GiB of memory. And yet it’s one of the most common causes of instability experienced by users and in the case of Firefox the biggest source of crashes on Windows. As such, at Mozilla, we spend significa
MemLab: An open source framework for finding JavaScript memory leaks
MemLab: An open source framework for finding JavaScript memory leaks We’ve open-sourced MemLab, a JavaScript memory testing framework that automates memory leak detection. Finding and addressing the root cause of memory leaks is important for delivering a quality user experience on web applications. MemLab has helped engineers and developers at Meta improve user experience and make significant imp
Your Jest Tests are Leaking Memory
Jest is designed in a way that makes memory leaks likely if you’re not actively trying to squash them. For many test suites this isn’t a problem because even if tests leak memory, the tests don’t use enough memory to actually cause a crash. That is, until you add one more test and suddenly the suite comes apart. In this article, we’ll walk through why it’s so easy for Jest to leak memory, how to t
Rustの `Arc` を読む(1): Arc/Rcの基本 - Qiita
概要: Rustの Arc 型の実装は宝の宝庫です。そこで、これを隅から隅まで解説してみます。 第1回「Arc/Rcの基本」では、実際に Arc のソースを読む前に Arc/Rc の使い方を解説します。 第1回 Arc/Rcの基本 第2回 Rcを読む基本編 第3回 Rcを読む発展編 第4回 アトミック変数とメモリ順序 第5回 Arcを読む はじめに Arc<T> はRustの基本的な型のひとつですが、 Box<T> のようにコンパイラに特別扱いされているわけでもなく、実装も比較的コンパクトです(コメントやテスト、安定性に関する指示などを除いて500LOC程度) その一方で Arc は並行性制御や Deref, ドロップチェッカー, Unpin, Layoutの扱いなどRustをよりよく理解するための題材を多く含んでいます。そこで本記事では Arc<T> の実装を読んでいきます。 とはいえ、
「強いメモリモデル」と「弱いメモリモデル」 - yamasaのネタ帳
Apple M1についての面白い記事を見かけて、久しぶりにメモリモデル屋(?)の血が騒いだのでブログを書く。 note.com 強いメモリモデル 現代のCPUアーキテクチャでは、x86(64bit, 32bitどちらも)が「強いメモリモデル」を採用しており、それ以外のメジャーなCPUが「弱いメモリモデル」を採用している。この「強いメモリモデル」「弱いメモリモデル」について、まずおさらいしておこう。 以下のように、2つの変数a, bに対して異なるCPUコアが同時にアクセスしたとする。 int a = 0; int b = 0; CPU1: a = 1; b = 1; CPU2: int r1 = b; int r2 = a; (上記はC言語に似た疑似コードを用いているが、実際は機械語命令になっていると考えてほしい。つまり、CPU1は変数a, bの示すメモリアドレスに対するストア命令を実行して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js — Using Heap Snapshot
Node.js — Tracing garbage collection
Debugging memory leaks in WebAssembly using Emscripten | Articles | web.dev
Total Canvas Memory Use Exceeds The Maximum Limit
例えばGCを止める - blog.jiikko.com
An update on Memory Safety in Chrome
