GCとの協調

skySchemeのプログラムは、スコープ間のやりとりをパケットの送受信で行うと仮定している*1。つまりデータのアップデートも返信のパケットによって行われ、インポートするのは呼び出し側の責任になる。(これはもちろん隠蔽されるし、非効率なので最適化フェーズでスコープ間を合成する。)

skyScheme→mosh

ホストScheme(この場合mosh)からみると、skySchemeの提供するオブジェクトは一つのprocessであり、受信動作によってオブジェクトに変換される。
これは常にコピーが発生するので大きな問題は発生しない。提供したprocessがゴミとみなされたときに適切にcleanupできるように配慮する必要が有る。

mosh→skyScheme

skySchemeにオブジェクトを渡した場合、mosh(というよりBoehm GC)からみると渡したオブジェクトがブラックホールに消えたように見える。skySchemeはメモリ管理にホストSchemeのオブジェクトシステムを使わない。
例えば、文字列をskySchemeの提供するprocessに対して送信する場合を考える。文字列を指すポインタがBoehm GCの管理していない領域におかれた場合、文字列は自動的に開放されてしまう。
対策は2通り考えられる。

通常のmallocを行うインターフェースを提供し、Scheme側でそれを使う。
例えば、オブジェクトをrootセットに追加する方法を用意して、skySchemeの生成したコードからは明示的に領域を開放する。

  • 呼び出しオブジェクトを作る

呼び出しオブジェクトを明示的に確保し、skyScheme側から(GC)freeできるようにする。
これは呼び出しのたびにアロケーションが確実に発生するのであまり好ましく無いように思える。
前者を効率的に行うためにはVMとの協調が必要になる。例えばスタック上にあるオブジェクトをskySchemeに引き渡した場合、skySchemeのコードからはそれをfreeできない(もちろん通常のシチュエーションではスタック上のオブジェクトを引き渡すことはしないが)。
もっとも、この問題は別のOSプロセスで動作するprocessや別のノードにオブジェクトを引き渡したときも発生する。

*1:skySchemeは基本的にスタックアロケーションを使わないし、プリエンプションも行われないことを仮定している。