割り込み処理: klic_interrupt

klic_interruptは、リダクションの切れ目にて、 ヒープ溢れが起きたかのように見えた時に呼び出される処理であり、 「実際にヒープが溢れた場合」、および「例外処理がおきたため、 擬似的にヒープが溢れたかのように見えた場合(heaplimit が0の場合) に呼び出される処理であった。

実際の処理は以下のように行われている。

1.

まず、resumeされているかもしれないゴールを通常のスタックに 書き戻す。これは、実行時ライブラリ中で行われた処理により エンキューされたようなゴールは大域変数resumed_goals にエンキューされている。 この二次的なゴールスタックにエンキューされているゴールを本来の ゴールスタックにエンキューし直す(ページ、第3.3.4章参照)。 この「エンキューし直し」処理を行う関数が runtime/intrpt.cで定義されている enqueue_resumed_goals()である。 

ここでは、まず、ここで述べたようなエンキューが完了していないような ゴールがあることを考慮し、まず、enqueue_resumed_goals()を呼びだしている。

2.

トレーサ対応のコードの場合、ここで、トレーサの処理をおこなう。  具体的には、stepping_flag、 trace_flagを参照し、を参照し、ONならば各々 step_after()、trace_after処理(共にruntime/trace.c内で定義 されている)を行う。詳細は、第8.3章 (ページ)を参照のこと。

3.

割り込みの原因を調査する。

• まず、以下で説明する「特殊な割り込み」以外の 「本来の割り込み処理」が必要かどうか検査する。 「本来の割り込み処理」がおきたかどうかは、signal_doneを参照することにより 判明する。割り込みがあった場合には、klic_signal_handlerを呼びだし、 必要な処理を行う(詳細後述)。その結果、heapに不足ができていないか判断する。

  また、割り込み処理もKL1のゴールにて実現することができるようになっている。 この場合、ゴールのエンキュー は前述の「例外的ゴールスタック」に対して行われるため、 enqueue_resumed_goalsを呼び出し、処理ゴールがもしあればスケジュールされる ようにしておく(先にheapに不足ができていないか判断している 一因は、このエンキューのためにヒープが消費されている可能性のあることである)。

• 割り込み原因がSIGINTによるものであれば、大域変数sigint_interruptが onになっている。これについてはその場でKLICの処理全体を終了させる。

• より高い優先度のゴールがエンキューされたのであれば、 大域変数higher_priority_goal がonになっている。 その場合には、次に実行しようとしていたゴールをエンキューし、 同変数をoffにし、最も高い優先度のキューに現在実行中のキューを置き換える。

  この「割り込み」は、通常のエンキュー時に起こる可能性があり、 汎用の(つまり、エンキューすべきゴールが、現在実行中の優先度 と同じであることが確定できない場合に呼びだされる)ゴールエンキュー 関数enqueue_goal()中で優先度を比較した上でセットする。 このエンキューはいわば同期的に行われるため、 前述の「割り込み用ゴールスタック」を用いずに、直接、通常の優先度付きゴール キューにエンキューされる。しかしながら、実行ゴールスタックの置きかえは やはりここで行われる。

• 真にヒープに溢れがおきたかどうか、検査する。 この検査は以下のように行われる。

      if (allocp + this_more_space >= real_heaplimit)
  

  このreal_heaplimitは、割り込み発生があっても、強制的に 0に起きかえられることのないheaplimitのコピーである。 this_more_space は、ヒープ不足で中断した計算を実行するために 最低限確保しなければならない 空きヒープ領域の容量を示している。

  上記のif文がtrueになった場合にはGCを起動する(klic_gcの呼びだし)。  GC呼び出し前後にGC_ON(), GC_OFFとあるのはマクロであり、 GC処理についての統計情報を確保するためのものである。