「継続の生成におけるスタックコピーの遅延」のメモ

論文CiNii -  Lazy Stack Copying fDr First-class Continuationsのメモ。

動作原理

  • (call/cc ) の 呼び出し中には呼び出し側の関数フレームは破壊されない事を利用する
    • この段階ではスタックポインタを記憶するだけでコピーする必要がない(不完全継続オブジェクト)
  • からリターンすると壊れてしまう可能性があるので、そのタイミングで継続を「昇格」させる
    • 特定のリターン時に特別処理を行う事を「リターンバリア」と呼ぶ
  • 昇格が必要な場合
    • 以前にキャプチャされた継続が呼び出された場合
  • 実行中に継続が「将来決して呼び出されない」と分かる事がある。参照がないなど。
    • この場合、リターンバリアで昇格する必要がない
    • スタックコピーの遅延で効率が良くなる
  • 昇格が不要なケース
    • に渡された継続が使われない場合
    • の大域脱出で使われる場合
  • 不完全継続を呼び出す場合は、スタックへの書き戻しコピーが発生しない
  • スタックコピーの共有
    • call/cc が入れ子になると不完全継続が複数できる
    • ある継続が昇格するときに、その継続に含まれる不完全継続も同時に昇格させる。スタックのコピーを共有。
  • ごみの判定
    • リターン時に継続が不要になったかどうかの判定が必要。
    • 昇格不要
    • 昇格必要の可能性
      • 継続の参照が、大域変数、ヒープに作られた
      • の戻り値が継続そのもの
    • 昇格予約フラグ
      • 参照が作られたときにセット(ライトバリア・オブジェクト生成時チェック)
      • 継続に不完全継続が含まれている場合(コピー共有で解決するはず)
  • 継続スタック
    • 不完全継続を貯めるスタック

実装用のメモ

  • のリターンをどこで見つけるか?
  • 昇格予約フラグコンパイル時に決定できる?
  • リターンバリアのオーバーヘッド?
    • 許容できる?

実装する?

リターンバリア、ライトバリアのオーバーヘッドが大きそう。保留。