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

GC(Garbage Collector)はオブジェクトを解放する手間が不要になる。世紀の大発明だったと言っても過言ではないだろう。しかし、それが便利なのかどうかは微妙なところだと思う。実際のところ、C#Javaでまともな(市販レベルの)プログラムが組まれるようになってきたのは、つい最近のことであり、公平に見て、試行錯誤段階だと言わなければならないだろう。

ファイナライザ(≒C++のデストラクタ)が呼び出されるのはGCがそのオブジェクトを解放した時なのだが、ファイナライザでリソースを解放するようなクラス設計をするとまずいことになる。たとえば、ビデオメモリのような外部リソース(.NETの用語ではunmanaged resourceと呼ぶ)を扱うと、その解放をファイナライザに期待しても無駄である。なぜなら、ファイナライザが呼び出されるのはGCがオブジェクトを回収する時であり、GCは自分の管理するGCヒープから確保したメモリが圧迫されない限り働こうとはしないからだ。

結果として、メインメモリはふんだんにあるのに、GCが働かないためunmanaged resourceが無尽蔵に使用され、ソフトがハングアップしてしまうことがある。これを避けるために、unmanaged resourceを扱う場合は、マネージャクラスを作ったり何なりしなければならない。

まあ、このへんの問題を少しでも緩和するためにGCを拡張する話も出ている。

WhidbeyGCが拡張される:
http://blogs.msdn.com/brada/archive/2003/12/12/50948.aspx

何せ、GCというのはまだまだ発展途上にある技術なのだということだ。状況によってはGC付きの言語よりC++のほうがはるかにマシだと言うことを肝に銘じておく必要がある。

やや余談になるが、携帯Javaなんてひどいもんだ。同じ理由でGCが働かないためにリソースを使い切ってしまうことがある。もともとメモリが火の車なので一刻も早く解放しなければならないというのに、悠長にGCがcollectするのを待ってられない。

もうそうなってくると、携帯Javaでは、GCに期待できない。またnewのオーバーヘッドも馬鹿にならないので、ゲーム開始時とかシーンの初期化時以外にnewを使えない。残る手段はC風にプログラムを書くことだ。こんなプログラム書くのなら、C++のほうが遙かにマシである。

おまけにJavaはリフレクションのためにクラスファイルに変数名を埋め込みやがるんで、変数名が長いとその分、jarファイルがでかくなって携帯に読み込めなくなったりする。おかげで、変数の使用頻度をカウントしてハフマン符号化のようにしてなるべく短い変数名と置換するソフトを用意しないといけなかったりしてくる。携帯の進化のスピードから察するに、こんな状態がまだ1,2年は続くと思われる。携帯にJavaを採用しようとか最初に言い出した奴は、とんだ食わせ者なんじゃないかしらん。