GCがどーの - 真 もわ爛漫 の続き
昨日、コメントに現れた人とは別の人 (初対面) とMMUにGC乗っけるとかそういう話をした。「だれもやってねーんじゃね？」という点以上には進展しようはないんだけど。
キャッシュされたメモリのアドレスとの整合性が取れないとまずまじぃ、という話になり、ところでキャッシュされるのは仮想メモリの方か物理メモリの方かという話になり、それはスイッチ出来ないとKernelとUserlandの両方の要求を満たせないよねー、ということになり、どうせ普通のPCならメモリ余ってるんだからとやかく言う前にまずプロトタイプを作らないと評価も出来ないという、なんというかどうでも良い結論になた。
MMUに押し込んだ場合はバンク毎に詰め込み、今日びGC走らせる言語の中でVM搭載する系統が多いんだからJavaマシンとか復活させれば良くね、なんて話もありつつ、JavaのVMの仕様は知らんのだけどおそらくスタックマシンは今でもハードに移植するとデグレ多すぎだー、という反論をしてみた。この話で一番興味深かったのは、VM上で走らせる場合、VMはメモリをブロック単位よりもはるかに大きいサイズで一括して下層のリアルマシンに要求して独自にメモリ管理するって下りで、それを仮想メモリ以下に落とせば良いというのが、筋が良さそうな妥協だとおもた。つまりVMな言語はメモリを仮想化してるんだから、それを仮想メモリに落とすことに何の理屈上の不都合があるんですか、ということである。蓮舫である。
問題は、回路に落とすのならTRIEみたいなループのない構造とかリファレンスカウント方式じゃないと大抵うまく行かず、GCの怖いのは循環参照だよねだからリファレンスカウントだけじゃダメなんだよねみたいな話で、4GBあったときに2GBだけ見せてCopying GCだゴルァ、という単純な話にならなそうなところかなーと。
ハードに落とせる最大のメリットはマークアンドスイープのマークフェーズを並列で走らせられるというところで、線形が対数くらいに落ちそうというところと、やっぱりソフトで書くより速いというのが大きい。
問題は、純粋関数型が標榜するような完全な形を望むと、現実には回路の複雑度が大きくなりすぎ、多分どっかで「ねぇ、ここだけソフトでやってくんない？」とかいうことに必ずなるだろうってこと。そこがどこかは、実際にハードとソフトの組を実装してみなければならず、そのためにはハードの実装 (シミュレータじゃなくて出来れば焼いた奴) が要り、実装するには金がかかり、金を投入するには良い実装が要るのである。それこそ循環参照だよもん。
後、これによってGCコントローラと言う層がさらに一層MMUに入るため、おそらく数十ステップ以上メモリが遅くなる可能性がある。でもさ、HDDほど遅くならなければパイプラインとコンパイラにやらせりゃいいんだと思うよ。どうせ今でもバーストモードじゃなかったらかなり遅いし、バーストモードでも最初のレスポンスはどうしようもない。
昔々に大量の命令積み込んだCPUよりRISCの方がいいじゃん、みたいな話になった帰結を考えるとハードはシンプルにとしたいところなんだけど、GCは流石に超絶枯れすぎている分野で要求が頻繁に変わるようなものでもなく、RISCの重要な一部分にしてもいいんじゃね、とか思う。もし可能になれば、仮想メモリといった仕組み以来のブレイクスルーになるかもしれない。
言語毎の細かい要求水準が異なるといった点は最初の時点では無視した方が良いと思う。ハードで見切りが付いたら、ソフトは奴隷のようにハードに追従してその特性を活かしきるというのがソフトが本質的に強い理由であって、ソフトの要求をハードに押し付けるのは最小限度であるべきだ。
そして、最小限度の要求にGCを要れるべきだ、というのが最近の私の印象。
