Downloaded 21 times
shared_ptrとゲームプログラミングでのメモリ管理
- 1.
- 2.
- 3. アジェンダ • はじめに • メモリリーク •メモリ断片化 • 処理速度 • まとめ
- 4. 今回の話の対象 • ハード：OSとゲームが動作するコンピュータ • ソフト：C++によるネイティブクライアント •ゲーム:アクションゲームなど、リアルタイム性が問われる ジャンル • 開発規模:中規模～大規模
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. メモリリーク • std::freeやdeleteを書き忘れると発生する • メモリ解放を他のプログラマに委ねるインターフェースでも メモリリークは発生しやすい voidSample() { void* pBuffer = std::malloc(1024); Player* pPlayer = new Player(); }//メモリリーク発生 void Register() { m_pPlayer = new Player(); } //呼び忘れるとメモリリークする void UnRegister() { delete m_pPlayer; }
- 12. RAII • Resource AcquisitionIs Initialization • オブジェクトの生存時間とリソースを結びつける • 基本的にこの設計を守ればメモリリークは起きない • 実装の一例として、shared_ptrを利用する
- 13. shared_ptr • newとdeleteは使わずにshared_ptrを使う • 各種モジュールごとにshared_ptrで分離させておくと、生ポイ ンタを扱わずに済む classPlayer { private: std::shared_ptr<Collision> m_collision; std::shared_ptr<Sound> m_sound; }
- 14.
- 15.
- 16. カスタムアロケータ • あらかじめメモリの確保、開放時にデバッグ情報を保存できる カスタムアロケータを作り、OSのアロケータを切り替えておく →デバッグ情報をログ出力することでメモリの状態を把握できる ゲーム デバッグ情報の保存 アロケータ void* _cdecloperator new (size_t size) { //カスタムアロケータ呼び出し }
- 17. メモリリーク検出ツール • ゲームプログラムにおいて、メモリリークが問題になった時のメ モリ状態を考える • メモリリークしているアドレスは開放されない →メモリの生存時間が長いアドレスはメモリリークの可能性が高い →アドレスに日付をつけるとメモリの生存時間を計算できる structNode { int64_t address; int64_t size; int64_t date; }
- 18. 生存時間の長いアドレス • 常駐データなど、メモリ確保後に解放しないデータもある • メモリ確保時にコールスタックを保存して、ログ出力に含める →コールスタックが１回のみ記録されているものは常駐データ →同一コールスタックが複数回記録されているものはメモリリー クの可能性が高い •コールスタックはRtlCaptureStackBackTraceなどで取得できる
- 19. メモリリーク検出ツール • 同一のコールスタックから、生存時間の長いメモリを複数回確保 している箇所はメモリリークしていると判断できる →エージングなどの自動テストに組み込むことで、メモリリークを自 動的に検出できる struct Node { int64_taddress; int64_t size; int64_t date; int64_t backTraceHash; } //keyはbackTraceHash std::map<int64_t,std::vector<Node>> nodes for(auto it = nodes.cbegin(); it != nodes.cend(); ++it) { if( 1 < it->second.size() ) { auto memoryLeak = it->second;//メモリリーク発見！ } }
- 20. アジェンダ • はじめに • メモリリーク •メモリ断片化 • 処理速度 • まとめ
- 21.
- 22.
- 23.
- 24.
- 25. 断片化対策 • 例:64bit Windows8.1 →プロセスあたりの仮想メモリ空間は128TByte →ページ単位のブロックアロケータを使い、仮想メモリ断片化は 気にしない •Windowsのlow fragmentation heapが参考になる • 断片化よりもアロケータの適切なページ管理が重要
- 26. 断片化対策 • MMUを搭載していて、仮想アドレス空間と実メモリに差が少 ない場合(32bitコンピュータにGByte単位の実メモリを載せて いる場合など) →仮想アドレス空間の断片化に気をつける必要がある • 例：32bit Windows XPで、メモリ使用量2GByteのゲーム Virtual memory Physical memory
- 27.
- 28.
- 29. 生存時間の長いメモリを減らす • ゲームシーケンスの切り替え時にモジュールを作りなおすよ うにする • シーケンス間のデータ移行のためのモジュールを作ることも ある voidLevelClear() { std::shared_ptr<Status> status = m_level->GetStatus(); m_level = std::make_shared<Level>(status); }
- 30.
- 31. 断片化対策 • 生存時間の長いメモリと、生存時間の短いメモリのアドレスを 離す →アロケータを複数用意する Double EndedStack allocatorを使うこともある Virtual Memory
- 32.
- 33. アジェンダ • はじめに • メモリリーク •メモリ断片化 • 処理速度 • まとめ
- 34.
- 35. メモリ動的管理の問題点と解決方法 • メモリリーク →RAII(shared_ptr)とメモリリーク検出ツールで解決 • メモリ断片化 → 仮想アドレス空間の広さを活用して解決 • 処理速度 → アロケータを高速化しつつ、処理速度に見合った ゲームにすることで解決
- 36. メモリが不足したら？ • メモリが不足しないようにゲームを作るのが基本 →自動テストやエージングを繰り返して、メモリ使用量を把握する • メモリリークとメモリ断片化を解決してもメモリが不足する場合は、 ゲームに対してデータが大きすぎるので、データを修正する autoplayer = std::make_shared<Player>(); player->Update(); //playerは必ず存在する
- 37.
- 38.
- 39.