How about "Explicit memory management"?
skySchemeはGCではなく明示的なメモリ管理を前提に設計している。もし、GCが利用されるようなケースがあるならば、それはホストSchemeで実行されることになる。
明示的なメモリ管理とは、オブジェクトの寿命が明示的に決定されていることを指す。skySchemeにおいては、パケットを受け取ってからS式にしてホストSchemeに引き渡すまで(あるいはその逆)がオブジェクトの寿命ということになり、内部状態を持つプロトコルを除いては多くの場合にストレートにオブジェクトの寿命が決定される。
個々のオブジェクトの寿命とmalloc,freeは対応しない。一つのオブジェクトのためにmallocを行うのはあまり効率が良くないため、複数のオブジェクトをまとめた構造体を"内部データ構造"の形で保持することになる。
しかし、これらのデザインは少々大胆すぎるという意見もあるのでもう少し見直すことを考える。
Quantifying the Performance of Garbage Collection vs. Explicit Memory Managementでは、Javaを題材にGCによる実行と(あらかじめ寿命調査したコードを用いて)明示的にmalloc,freeを行う実行を比較し、GCは十分なメモリがあれば明示的なメモリ管理に匹敵すると結論している。逆に、十分にメモリが無かったりするケースではこれが問題になる。
(2005年当時と比べて、)現代的には、メモリ帯域は十分な問題となりつつあり、今後GCが明示的なメモリ管理に対して同等なパフォーマンスを大量のオブジェクトに対しても実現できるかは疑問に思える。
課題と疑問
課題は現実のアプリケーションにおける性能だろう。残念ながらRnRSで書かれたSchemeコードは現実的な問題を評価できるほどの数は無いので、多分JVMを実装するのが好ましい。
ただ"機能する"JVMを実装することに対する困難性に関してはなんとも言えない。
skySchemeのように静的な型付けを行うということは、GCのコードを生成できるという可能性を拓く。つまり、現在はデータに付与されたタグからデータがポインタかどうかをチェックしているが、そのチェックをおこなうことなくクラスごとにGCのコードを生成して差し替えるという方向性が考えられる。
もっとも、このような方向性にメリットが無いのはほぼ明確で、潤沢なメモリさえあれば同等の性能をよりシンプルなアプローチで達成できるだろう。
