GC付きの言語におけるゲームプログラミング(2)

さて、携帯のような省メモリ環境におけるGCのまずさを書いたところで、Windowsマシンのようにふんだんにメモリのある環境でのGCの挙動について考えていこう。

まあ、メモリがふんだんにあるとは言ってもビデオメモリのようなリソースは限度があるので、unmanaged resourceを扱うクラスのファイナライザの早期呼び出しをGCに期待できない。結果として、ビデオメモリに対するpressure、早いはなしが、ビデオメモリをなんぼ使っとるねん？ってなのを管理しておき、やばくなってきたら古くにアクセスされたものから解放していくような仕組みを自前で用意してやる必要がある。いわゆるcache mechanismだ。すべてのunmanaged resoureのアクセスは、このようなcache mechanismを通じて行なうように設計しなければならない。これがGC付きの言語での実情である。画面にテクスチャ１枚貼り付けるためだけにこのような仕組みを通じて行なうのは多少面倒にも感じるが、まあ、許せる範囲だと言えるだろう。

しかしまあ、そうやってunmanaged resourceを管理しないといけないということは、GCには何も頼っていないわけで、C言語と同じようなプログラミングスタイルに帰着すると言える。

結局、C言語でメモリリークさせないように注意深くプログラムしなければならなかったの同様、GC付きの言語でもunmanaged resourceが適切なタイミングできちんと解放されているのかを注意深くプログラムして行かなければならないのだ。こうなってくると、ゲームプログラミングにGC付きの言語を採用することはGCの存在自体にアドバンテージがあるのかどうか疑問ではある。しかし、実際のところC++にdelegateやcontinuationのサポートを期待することは出来ないし(どちらも自前で用意することは出来なくはないが)、そう考えていくと結局のところはC#あたりに落ち着きそうな気もする。これについてもう少し考えていこう。(つづく)