「メモリ」タグの記事が9件件あります

Chromeにおけるメモリ安全性は、ユーザーを保護するために絶え間なく進行中の取り組みです。私たちは常に悪意のある行為者を一歩先んじるために、さまざまな技術を試験しています。その一環として、本投稿ではC++のメモリ安全性を向上させるためにヒープスキャンニング技術を使用した私たちの取り組みについて紹介します。

メモリとパフォーマンスの間には常に戦いがあります。ユーザーとしては、速度が速いことを望むと同時に、できるだけ少ないメモリ消費で済ませたいと思います。しかし、通常、パフォーマンスを向上させるにはメモリ消費の代償が伴い（その逆も然り）、ジレンマを抱えることになります。

2018年末、私たちはV8のメモリ使用量を劇的に削減することを目指してV8 Liteというプロジェクトを開始しました。このプロジェクトは当初、低メモリモバイルデバイスやメモリ使用量の削減を重視したエンベッダー利用ケース向けに、V8の別のLiteモードとして構想されていました。しかし、この作業の過程で、このLiteモードのために行った多くのメモリ最適化が、通常のV8にも適用可能であり、V8のすべてのユーザーに利益をもたらせることに気付きました。

ここ数年で、V8のガーベッジコレクター（GC）は大きく変化しました。オリノコプロジェクトは、逐次処理型の完全停止ガーベッジコレクターを、主に並列および同時並行のコレクターとして段階的フォールバックを持つ形に変革しました。

V8でのJavaScriptオブジェクトは、V8のガベージコレクタによって管理されているヒープ上に割り当てられます。以前のブログ記事では、ガベージコレクションの停止時間を短縮する方法（複数回）やメモリ消費量を削減する方法について既に説明しました。本記事では、Orinocoの最新機能の1つである並列スカベンジャーを紹介し、V8のガベージコレクタの設計決定や、進行途中で実装した代替アプローチについて議論します。

約3か月前、私はインターンとしてV8チーム（Googleミュンヘン）に参加し、それ以来VMの_Deoptimizer_に取り組んできました。このプロジェクトは完全に新しいものであり、興味深く挑戦的なものでした。インターンシップの最初の部分ではVMのセキュリティ面の改善に焦点を当てました。そして2つ目の部分ではパフォーマンス改善、具体的には非最適化された関数の解除に使われるデータ構造の削除に取り組みました。このデータ構造はガベージコレクション中にパフォーマンスボトルネックとなっていました。このブログ投稿ではこのインターンシップの2番目の部分について説明します。V8が以前どのように非最適化された関数を解除していたか、どのように変更したか、そしてどのようなパフォーマンス改善が得られたかを説明します。

メモリ消費は、JavaScript仮想マシンのパフォーマンストレードオフ空間において重要な次元となります。過去数か月間、V8チームは近代的なウェブ開発パターンの代表とされる複数のウェブサイトのメモリフットプリントを分析し、大幅に削減しました。このブログ記事では、分析に使用したワークロードとツールを紹介し、ガーベッジコレクタにおけるメモリ最適化の概要を述べ、さらにV8のパーサーとコンパイラーで使用されるメモリの削減方法を示します。

ジャンク、言い換えれば目に見えるスタッター（処理の遅延）は、Chromeが16.66ms以内にフレームをレンダリングできない場合（60フレーム毎秒の動きが邪魔される）に発生します。現時点では、V8のガベージコレクションのほとんどがメインレンダリングスレッドで実行されています（図1参照）。これにより、多くのオブジェクトを管理する必要がある場合にジャンクが発生することが多々あります。ジャンクの排除はV8チームにとって常に最優先事項でした（1, 2, 3）。この記事では、Chrome 41からChrome 46までに実装された最適化について説明し、ガベージコレクションの一時停止を大幅に削減し、ユーザー体験を向上させる結果となったものを紹介します。

JavaScriptのパフォーマンスはChromeの価値の重要な側面の1つであり、特にスムーズな体験を実現する上で重要です。Chrome 41以降、V8は新しい技術を利用して、アイドル時間内の小さな未使用時間に高コストなメモリ管理操作を隠すことで、Webアプリケーションの応答性を向上させています。この結果、Web開発者はガベージコレクションによるジャンクが大幅に軽減され、スムーズなスクロールや滑らかなアニメーションを期待することができます。