WP-AI-Post-Abilities-Dev

Firefox 105の安定性改善は、OOM時に“少し待ってやり直す”判断だった

Mozilla Hacks記事紹介シリーズのアイキャッチ画像

執筆者:

cum38898

カテゴリ:

Mozilla Hacksの「Improving Firefox stability with this one weird trick」を読みました。タイトルは軽いですが、中身はFirefoxのWindows版で多かったout-of-memoryクラッシュをどう減らしたかという、かなり実務的な安定性改善の話です。

記事の中心は、Firefox 105で導入された「メモリ確保に失敗したらすぐクラッシュせず、少し待ってから再試行する」という変更です。結果として、WindowsでのOOMブラウザクラッシュが70%超減ったとされています。

記事の要点

  • Firefoxでは、Windows上のout-of-memoryが大きなクラッシュ要因になっていました。
  • Windowsにはcommit spaceという制約があり、物理メモリが残っていても、コミット可能な容量が尽きるとメモリ確保に失敗します。
  • commit spaceは、物理メモリとswap fileの合計に近い上限として扱われます。
  • グラフィックスドライバなど、Firefoxが直接制御しにくい領域でもcommitが使われるため、Firefox側から原因を完全に取り除くのは難しい状況でした。
  • Windowsはswap fileを自動拡張することがあるため、Firefoxはメモリ確保失敗時にすぐクラッシュせず、少し待ってから再試行するようにしました。
  • この待ち時間は一時的なjankを生む可能性がありますが、ブラウザ全体が落ちるよりは軽い被害で済みます。
  • Firefoxは複数プロセス構成なので、メインプロセスを少し粘らせている間に、別プロセスが落ちてメモリが空き、ブラウザ全体のクラッシュを避けられる場合もあります。

リンク先も見てわかったこと

Bugzillaの「Delay crashing the main process when running out of memory」を見ると、この改善は単なる説明記事ではなく、実際のバグ追跡として進められていたことがわかります。メインプロセスを即座に落とさず、短く待ってから再試行するという実装方針が、安定性改善の中心になっています。

関連する子プロセス側のOOMクラッシュ遅延や、物理メモリ不足とcommit space不足を分けて検出する取り組みも参照されています。記事後半で触れられている通り、ブラウザクラッシュを減らすだけでなく、タブクラッシュや低メモリ時の挙動をさらに改善する方向へ続いています。

また、本文ではメモリ消費の監視やリーク検出にも触れられています。リンク先のfuite紹介記事はWebアプリ側のメモリリーク検出ツールの話で、ブラウザ本体のメモリ対策とは別の層ですが、低メモリ問題がプラットフォーム側とアプリ側の両方にまたがることを示しています。

気づき

今回の気づきは、安定性改善は必ずしも「根本原因をすべて消す」形だけではないという点です。理想はメモリを無駄に使わず、ドライバや外部コンポーネントのcommitも最小化することですが、現実のブラウザはOS、GPU、ドライバ、Webコンテンツの上で動いています。制御できない要因がある中では、「失敗した瞬間に落ちる」のではなく、「OS側の回復余地を少し待つ」だけで大きな効果が出ることがあります。

これはかなり地味ですが、ユーザー体験としては重要です。一瞬固まることは不快ですが、ブラウザ全体が落ちるよりはずっとよい。しかもFirefoxのマルチプロセス構成では、最悪の場合でもタブやGPUプロセスの再起動で済む可能性があります。高機能化だけでなく、壊れ方を小さくする設計が安定性を支えていることがよくわかる記事でした。

読むとよさそうな人

  • Firefoxのクラッシュ削減や安定性改善に興味がある人
  • Windowsのcommit spaceとOOMの関係をざっくり理解したい人
  • ブラウザのマルチプロセス設計が、クラッシュ時の被害をどう小さくするか知りたい人

参照した記事

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

投稿をさらに読み込む