« プラグインの分断と整理 | メイン | ビットマップメモリ確保失敗追加対策等 »
2016年08月05日
吉里吉里Z 開発:: 断片化によるメモリ確保失敗を回避する設定と考察
Tweet @jin1016をフォローよく発生すると言うゲームを買って、いくつか設定を試しつつ動かしてみた。
実際に初期設定で動かすと本当に30分~1時間で発生する。
動作を予想しつつ試して、以下の設定にするとほとんど発生しなくなった。
Visual Studio についている EDITBIN で吉里吉里Z本体の exe の LARGEADDRESSAWARE を有効化して、32bit でも 4GB 弱までメモリを使えるようにする。
デフォルトでは 2GB までしか使えない。
ただ、GlobalAlloc などでは特に効果は見られなかったので、設定の意味はあまりないかもしれない。
最新の吉里吉里Z 32bit版では有効にしてビルドされている。
エンジン設定で以下の設定を行う。
画像キャッシュ制限を「キャッシュを行わない」に。
キャッシュに残っているとコンパクションが阻害されてしまうので、ない方が断片化が進行しづらい。
OFF だとスキップなどで速度低下の発生が懸念されるが、最近の PC で SSD なら少し遅く感じるところもあるが許容範囲だと思われる。
なしではなく数百MB(100~200)辺りであれば、それほど影響はないかもしれない。
ビットマップメモリ確保方式は、「分割ヒープを使用」に。
初期分割ヒープサイズは、「1GB」(誤字で1GMBになっているのに気付いた)
エンジン設定後、savedata/exe名.cfu に 「ghcompact="\x79\x65\x73"」 の1行を追記。
この設定はドキュメント未記載(追加忘れていた)。
System.doCompact(clAll) が実行されるシチュエーションで Process/CRT ヒープのコンパクションを呼び出し、断片化の進行を抑止する。
設定は以上。
上記設定で最終的に落ちたのはロック(スクリーンセーバーやディスプレイOFF等)中の描画でのメモリリークっぽいので、ずっとプレイしている状態だと落ちないかもしれない(少し離席して復帰した時落ちていた)。
ロック中の描画でのメモリリークについて解析を進めて早く不具合修正をした方が良さそう。
後、メモリ不足で落ちた時の System.dumpHeap() が欲しいところ。
Bitmapメモリ確保失敗時にログに System.dumpHeap() を書き出して解析できるようにしておく方が良いか。
分割ヒープの場合、その中から画像キャッシュが割かれるので、サイズ自動の時は分割ヒープサイズを考慮して画像キャッシュ容量を決めるように修正した方が良さそう。
外側から見た感じだとこの辺りの予想が限界だが、色々と気付くことがあってよかった。
投稿者 Takenori : 2016年08月05日 20:16
comments powered by Disqus