日別アーカイブ: 2009年2月19日

WindowsMobile のメモリ

WindowsMobile6.x がもう一世代継続されるようです。

米マイクロソフト、スペインで「Windows Mobile 6.5」発表

今でもプラグインが多いと SIP が読み込めなかったり切り替わらなかったり、
ブラウザのようなメモリを多く消費するアプリが不安定になったりしています。
WindowsMobile6.x のカーネルは WindowsCE5.2 で、WindowsMobile5.0 とそれほど
大きく変わっていません。
下記のページで詳しく解説されています。

Windows CE .NET の高度なメモリ管理

これを見ると CE4~5 のメモリ管理は下記の構造になっていることがわかります。

(1プロセス 32MB × 32プロセス) + 32MB の XIP DLL 空間 (ROM DLL)
  + ラージメモリ空間(992MB) + カーネル空間(2GB)

CE の限界は、上記の通り 1プロセスあたりのメモリ空間が 32MB に制限されていること。
最近の端末では 128MB~256MB の RAM を搭載していますが、1つのアプリケーションが
メモリ空間的に限界に達しているときは、いくら物理メモリを増やしても効果がない
ことがわかります。(desktop Windows でも 32bit OS だと 2GB まで、という制限に似ています)

32MB の XIP DLL 空間は、ROM にあらかじめ組み込まれている DLL を配置するための
領域だそうです。system の共有 DLL が XIP 空間に配置されている場合は 32MB の
プロセス領域を消費しません。

ROM に含まれていない (XIP でない) DLL は XIP 空間に配置できません。
こちらはプロセスのメモリを消費します。さらに DLL はプロセス間で共有されるために
ロードしたアドレスが固定されてしまうようです。
よって SIP プラグインなど、後から追加した dll が多数読み込まれている場合は、
各アプリケーションで使用可能なメモリ空間を食いつぶしてしまう可能性があります。

たとえば XIP でない DLL の合計が 16MB あって、かつ最もよく使われる dll が
一番下位のメモリにロードされてしまった場合。またはアプリケーションが複数の
dll をロードする構造の場合、最悪アプリケーションが使用可能なメモリ空間も
16MB になってしまうということです。

これらのこの問題に拍車をかけているのがもう 1つの制限、プロセス数の上限が
32個ということ。常駐するアプリケーションはプロセスを消費しないようサービス
として dll 化することが推奨されていているため、dll 空間を余計圧迫している
可能性があります。また単一のプロセス空間を取り合うため、dll を配置する
サービス用の空間自体も限界に達してしまう可能性もあります。

常駐する dll が多い場合、追加で dll 自体をロードできなくなる場合があること、
またブラウザなどの大きなアプリが不安定になる可能性があることがわかります。
メモリが大量にある場合、dll の共有はかえって逆効果なのかもしれません。

ただ実際に touchkeysip が読み込まれなくなる場合、どの段階で限界が来ており
どこのメモリ確保でエラーが出ているのかきちんと調べたわけではないので、
上の説明もいろいろと憶測が含まれています。あらかじめご了承ください。
単に touchkeysip が悪いだけの可能性もあります。

データ領域に限っていえば、ラージメモリ領域を使用することが出来るためまだ余裕は
ありそうです。上の MSDN のページに書いてある方法で大きなメモリブロックを
まとめて VirtualAlloc で予約すると、ラージメモリ領域に配置されるとのこと。

・常駐する dll を減らす。
・常駐する dll は一番先に読み込ませておく。
・アプリが消費するヒープメモリは自分でラージメモリから確保する。
・アプリを使い終わったらすぐ終了させる。特に独自の dll を使うもの。

等が有効かもしれません。

WindowsCE6.0 (WindowsMobile7) 以降は一般的な 32bit OS と同じ 2GB に拡張され、
プロセス数の制限もなくなるはずです。逆に普通の Windows に近づくので
CE である必要性が徐々に薄れていくような気もします。
先があることがわかっている中に出る 6.5 は Me を思い出してしまいます。

関連エントリ
emobile EM・ONE 使い切れないメインメモリ