検索
連載

Firefoxは「メモリ食い」という悪評を払拭できるかOSS界のちょっと気になる話(3)(2/2 ページ)

皆さんの中で、Firefoxをご利用の方はどれくらいいますか? すぐにメモリが足りなくなるなぁと思いながら使っている人もいるでしょう。しかし、Firefoxを開発しているMozilla Foundationも問題を放置しているわけではありません(編集部)

Share
Tweet
LINE
Hatena
前のページへ |       

改善活動MemShrink

 Firefoxは2011年6月から「MemShrink」と呼ばれる活動を始め(主要担当者は同年3月にはプロジェクトの前段階となる活動を開始している - MemShrink, March 10, 2011)、メモリ使用状況の調査分析および改善に本腰を入れるようになる。

 これまでのMemShrinkの活動は地道な改善が多かったが、それをいくつも繰り返すことで、状況は大きく変わりつつある。改善が進んできた様子はMemShrinkのブログを読むとよく分かる。毎週活動内容の報告があり、報告には、どういった改善を実施してきたのかが克明に記してある。以降では、MemShrinkの活動の中でも大きな成果を挙げたものを紹介していく。

「about:memory」から始まった

 MemShrinkの取り組みが始まってから、さまざまな形で改良改善が進んできたが、活動開始当初からの一貫したテーマであり、現在もより高いレベルを目指して改善を進めているのが、メモリの使用状況のレポート機能だ。Firefoxのアドレスバーに「about:memory」と入力して[Enter]キーを押すとレポートが表示される。

 Firefox 4.0で「about:memory」を実行してFirefoxが返すレポートは図2のようなものだった。どの程度メモリを使用しているのか報告しているだけで、どの用途にどれだけのメモリを使っているのかといった具体的な情報は得られない。

図3 Firefox 4.0で「about:memory」を実行した結果。OSはUbuntu 11.04。クリックすると拡大
図3 Firefox 4.0で「about:memory」を実行した結果。OSはUbuntu 11.04。クリックすると拡大

 「about:memory」を実行して得られるデータは、より詳細に、よく分かりやすく、問題の特定がより容易になるような形にすべく改善が続いている。Firefox 13.0a1では図3のような表示になっている。どのプログラムがどれだけメモリを消費しているのか細かく表示している。さらに、メモリの使用状況の表示形式がツリー形式になっている。展開や畳み込みが可能で、注目したい項目をじっくり調べたいというときに見やすいようになっている。Firefox 4.0当時と比較すれば大きな躍進だ。

図3 Firefox 13.0a1の「about:memory」実行結果。OSはUbuntu 11.04。クリックすると拡大
図3 Firefox 13.0a1の「about:memory」実行結果。OSはUbuntu 11.04。クリックすると拡大

 Firefox 13.0a1では、画面をスクロールさせないとすべての情報が見えないほど多様な情報が出てくる(図4)。

図4 図3の出力の続き。新しいFirefoxでは、メモリ使用状況をより細かく把握できる。クリックすると拡大
図4 図3の出力の続き。新しいFirefoxでは、メモリ使用状況をより細かく把握できる。クリックすると拡大

 今後はグラフ形式で表示する機能などが加わる計画になっており、さらに詳細にメモリの使用状況を把握できるようになるだろう。MemShrinkの活動が始まった当初、いったいどの機能がどの程度メモリを使っているのか、どの程度が「無駄」になっているのか、実情をまるで把握できていなかった。問題を改善するにはまず問題を把握する必要がある。「about:memory」はそうした取り組みの根幹となるものであり、Firefoxのメモリの使い方の改善度合いを示す指標と言えるものになっている。

 MemShrinkの活動開始当初、どんなプログラムが使っているのか分からないメモリ領域である非分類ヒープ(heap-unclassified)が全メモリ使用量の30%から45%ほどを占める有様だったが、最新版ではこれがほとんどなくなっている。メモリがどの用途にどれだけ使われているのか、もはや不明な部分はほとんどないところまで整理が進んでいる。

主原因を突き止めたMemShrink

 MemShrinkの取り組みをまとめた毎週の報告には、細かい改善しか載らない時もあれば、大きな効果を挙げた改善が載ることもある。それでも、ほとんどの関係者が驚くような改善点はなかなか見つからない。

 しかし、2011年8月5日(米国時間)の「Clownshoes available in sizes 2^10+1 and up!」は関係者の度肝を抜いた。「まさかこういうことだったのか」と目を丸くした開発者は少なくなかっただろう。

 それまでFirefoxは、既存のメモリリポーターが捕捉できていないメモリ領域を「heap-unclassified」と分類していた。要は正体不明ということだ。正体が不明であることからこれを揶揄して「ダークマター」と呼ぶ開発者も多かった。先に紹介した2011年8月5日(米国時間)の投稿では、ダークマターの原因の1つが「スロップ(slop)」であることを突き止めたと説明している。次の文章は、先に挙げた"Clownshoes available in sizes 2^10+1 and up!"からの抜粋だ。

“This week I realized that some of the dark matter could be due to "slop" from jemalloc, the browser’s heap allocator. What is slop? When you ask a heap allocator for a certain number of bytes, it’ll often give you back more than you asked for, rounding the size up. This wastes some memory, but there are good reasons for it - it makes the heap allocator much faster and simpler, and helps avoid fragmentation when the memory is freed.”

(今週、Webブラウザのヒープアロケータjemallocの「スロップ(slop)」によっていくらかのダークマターが引き起こされていることを突き止めた。スロップとは何か。ヒープアロケータに特定のバイト数のメモリ領域確保を依頼すると、ほとんどの場合、要求したサイズの数字を切り上げて、指定のサイズよりも大きめのサイズが確保される。この動きはメモリを浪費しているが、ヒープアロケータの動作をシンプルかつ高速にしている。さらにメモリが解放された後、メモリ空間にフラグメンテーション(断片化)が発生することを避けることにつながるという、いくらかの優れた理由がある。)

 メモリ管理を容易にするために導入した仕組みそのものによって、誰も使わない無駄なメモリ領域(スロップ)が生まれているということだ。jemallocが採用しているこうしたメモリ確保の方針はそれほど珍しいものではなく、メモリ空間の見通しを良くするために使うことも多い。しかし、実際にはこの仕組みが多くの「誰も使わないメモリ」という無駄を生んでいたことが判明したわけだ。

メモリ確保のコードを変更

 スロップによって生まれる無駄を排除するには、要求にあるメモリサイズとjemallocが実際に確保するメモリサイズを一致させれば良い。「Clownshoes available in sizes 2^10+1 and up!」では、改善につながる興味深い事実を紹介している。

 従来のソースコードを見ても、当然ながらスロップが発生しないような気遣いは見られるという。ただし、メモリの使い方にまずい部分があるそうだ。例えば、データサイズ領域そのものはjemallocが確保するのと同じサイズを確保しているものの、実際にはそこに小さなヘッダ分のサイズを追加したサイズをアロケータに対して要求しているものがあるという。要求サイズが2の倍数をちょっとだけはみ出たサイズになるということだ。その結果、実際にはアロケータは要求にあるサイズのほぼ2倍の領域を確保し、しかもその確保したメモリ領域の半分はまったく使われない領域になってしまう。メモリ領域の最悪の無駄遣いが横行していることが明らかになったわけだ。

 ダークマターの一部がスロップであることが判明してから、ダークマターの解明とabout:memoryレポートへの反映が続いた。現在ではダークマターのほとんどは解明できており、どの機能がどの程度のメモリを使っているのかがほとんど明らかになっている。

メモリ節約の成果でユーザーを呼び戻せるか?

 メモリの使い方そのものの改善のみならず、既存の機能の見直しや、動作の変更、新しい実装での置き換えなどが進み、リリースを重ねるごとにメモリ使用量は減少している。MemShrinkでは、今後改善すべき対象もはっきり捉えており、そのための作業を進めている。少なくとも向こう何回かのリリースを注意深く見ると、確実にメモリ使用量が減少しているだろう。

 メモリ使用量の削減はPC向けのFirefoxに限った取り組みではない。FirefoxにはAndroid版もある。Androidが動作するスマートフォンやタブレットのコンピュータリソースはPCよりも明らかに少ない。Android向けFirefoxで、メモリの使用量が減るということにはPC向けのFirefoxのメモリ使用量が減ること以上に大きな意味がある。Firefoxが省メモリ化に力を入れる背景にはこうしたAndroidへの進出という事情もある。

 IT業界は技術の進歩が極めて速い。特にWebブラウザ関連技術が発展するスピードは目を見張るものがある。半年前の常識は、もう現在では非常識ということさえある。メモリの使用量が多いという理由でFirefoxから別のWebブラウザへ移行したという人にはぜひとも、最新のFirefoxを見てほしい。メモリを浪費しないし、今後継続した改善も期待できる。特に大量のタブを同時に開くような用途では、最近のFirefoxはメモリ消費量の少なさと、軽快な操作という点において高い評価を得ているくらいだ。

著者紹介

▼ オングス代表取締役。

▼ 後藤大地

@ITへの寄稿、MYCOMジャーナルにおけるニュース執筆のほか、アプリケーション開発やシステム構築、『改訂第二版 FreeBSDビギナーズバイブル』『D言語パーフェクトガイド』『UNIX本格マスター 基礎編〜Linux&FreeBSDを使いこなすための第一歩〜』など著書多数。



 

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る