« 断片化によるメモリ確保失敗を回避する設定と考察 | メイン | 吉里吉里Zで扱われる各種文字コード »
2016年08月08日
吉里吉里Z 開発:: ビットマップメモリ確保失敗追加対策等
Tweet @jin1016をフォロー断片化によるメモリ確保失敗を回避する設定と考察に書いたような対策を加えたスナップショットを公開した。
動作を見て加えた対策だけど、今後気付くことがあったらまた追加対策する可能性はある。
これでも厳しいようなら 64bit版使えばいいと思う。
64bit版対応は、プラグイン対応とテスト工数の問題だろうけど、このメモリの問題に延々と悩まされるくらいならさっさと 64bit版対応した方がみんな幸せ。
・ロック画面での描画でメモリ消費量が増大する問題を修正。
・ghcompact が設定に漏れていたので追加。
・Bitmap メモリ確保失敗時、ヒープの状態をダンプして解析を進めやすいように追加。
・Bitmap 用分割ヒープ割当量計算方法を変更。
・分割ヒープを仮想メモリの空きと物理メモリで少ない方を基準に計算するように変更。
・グラフィックキャッシュを物理メモリより仮想メモリの方が小さい(32bitでメモリ搭載量が多い)場合、仮想メモリの方でキャッシュ計算するように変更。
追加したエンジン設定の ghcompact はデフォルト OFF。
ON にすると System.doCompact が実行されるタイミングで、idle 以上ならヒープのコンパクションも実行されるようになる。
以前は、clAll の時に限定していたが、デフォルト OFF でそこまで負荷も高くないようなので、idle 以上とした。
動作下限とする CPU のマシンで動かして負荷が気にならないのなら、デフォルト ON 設定にしてしまってもいいと思う。
今後ビットマップメモリ不足が発生した時、ヒープの状態から解析を進めやすいようにログにヒープ状態ダンプを行うようにした。
ログからフラグメンテーションがどれくらい進行しているかわかる。
分割ヒープ容量が自動の場合、空きメモリの内の割り当て量が以前よりも多くなるように調整した。
グラフィックキャッシュ容量が自動の場合、以前は物理メモリ量を基準に計算していたが、32bit の時は物理メモリの方が多いケースもあるため、仮想メモリ容量(32bitの時LAA有効で4GB、無効で2GB)と比較して小さい方基準で計算するように変更した。
前回のリリースでプロセスヒープをデフォルトとしたが、個人的には分割ヒープの方が有効ではないかと思っている。
今回のバイナリで利用が激しい環境でテストしてみないことにはどちらの方が発生しづらいかはわからないが。
ビットマップメモリ確保失敗が頻発するようなら、比較確認して結果を教えてもらえると助かります。
スクリプト側では、シーン切り替えの暗転時などに System.doCompact を呼ぶと少し効果があると思われる。
グラフィックキャッシュは使わないか、出来るだけ少ない容量にした方がメモリのフラグメンテーション抑止に効果がある。
投稿者 Takenori : 2016年08月08日 20:53
comments powered by Disqus