REDUCE/SUSPEND ポートのトレースのきっかけ

   

上述のように CALL ポートで実行を継続する場合、 ヒープの上限値をダミー値 に設定した後に実行を継続する。 これによって、 1 リダクションを経た後に ヒープあふれの割出しが起きる。 別途用意したトレース・フラグを用いれば、 本当のヒープあふれなのか、 トレースのためのダミー処理なのか (あるいは両 方か) を区別することができる。 これによって、 ヒープあふれ処理ルーチン の入口から、 上述の REDUCE ポートをトレースするルーチンを呼び出すことが できる(klic_interrupt(), runtime/intrpt.c)。

変数が未定義であったためにゴールが実行を中断することもある。この場合に は中断処理のためのルーチンが呼ばれる (ページ、第4.2章参照)。トレース用のライブラリ中では、 トレース・フラグを調べて、 必要なら SUSPEND ポートのトレー スを行うルーチン、trace_susp()またはstep_susp() を呼び出す。 中断処理自体かなりのコストを伴うので、 フラグの検査のオーバヘッドは相対的に小さい。 したがって、 トレース用ラ イブラリを用いても、 実際にトレースを行わない場合の効率はほとんど落ち ない。

CALL ポートでそのゴールのトレースを不要と指示されれば、 このようなヒー プ上限値とフラグの設定を行わなければ良い。