ガベコレ

なにをきっかけにしたか忘れたんだけどリソースのGCというものについて考えてみた。会社で暇潰しにWin32のコード書いてるときだったっけなぁ…暇じゃなかったんだけど。ファイナライザについて調べたときだったかな…まあそれはいいか。

僕が軽くGC否定派（あくまで軽くね）であることは、これまでに何回か書いてきたかと思う。
その一番の理由は、GC推進派が「今のGCは研究が進んで、相当効率がいい」などと、適当なことを言ったり言わなかったりするからなんであるけど、その話は置いといて、非メモリリソースの管理ができない、とか、そういう話だ。

GC載せてる言語でこの点について考慮されてる例ってあるだろうか。Rubyで「ファイルディスクリプタが足らなくなったらGCを実行する」みたいな記述をみたことがあるような気がするんだけど、どうだったっけ。ん、まあ、それでも十分大丈夫なような気がしてきた。

話が終わってしまった…これから適当に「非メモリリソースには参照カウントを使えばイイよね！！」みたいな話に持っていく予定だったんだけど、ただのmark-sweepでどうにかなるんだったら、それで十分だろう。ただ、まあ、一応GC推進派は「ファイナライザに頼ってはいけない」って言ってるので、そこらへんに難癖つけて、「Rubyの例はファイルオブジェクトのファイナライザに頼ってるから駄目だよー」っていうことにしておこう。あー、あと、「明示的にGC呼ぶのも駄目だ」とかもあるので、そこらへんとか。

ちょっと脇道にそれるんだけど、GC付き言語的には「ファイナライザに頼る」、「C++のdeleteみたいに手動で削除できる」、「GCを手動で呼ぶ」というのは基本的にタブーとされてんだけど、これ、非メモリリソースが絡むと、矛盾してくるんだよな。最終的に、全てのルールを守るわけにいかなくなる。結局のところ、大抵の言語では、「ファイルは使ったらclose()してください」ってなってて、「手動で削除する」っていうのを行なってるわけなんだけど。
でも、「ファイナライザに頼る」コードを書いてしまうと、GCが保守的なアルゴリズムだった場合に、状況によって動いたり動かんかったりするし、「GCを手動で呼ぶ」コードを書いてしまうと、GCがインクリメンタルだった場合に、予想とは違う動きをしてしまうかもしれない、とか、考えると、そこらへんは仕方無いかもしれないな…とか思う。
非メモリリソースの手動解放を要求するんだったら、いっそのことメモリも手動解放できたら現実的っぽくて素敵だと思うんだけど。

まあいいか。非メモリリソースは滅多に循環しないだろうから参照カウントでいいんじゃないか。って書きたかったんだけど。結論としては、「ファイナライザも使い方次第」ってところかなー。