KL1は自動メモリ管理を前提とした言語であり、KLICでは、 ``stop and copy''方式のGCを採用している。 つまり通常のKL1のデータはヒープに置かれ、 適当な時にKL1プログラムの実行を中断し一括的に回収される。 特筆すべきことは、通常のKL1データだけではなく、ゴールレコード、 ゴールの中断に必要な付加的なデータなど、動的に増減するものの殆どは ヒープ中に置かれており、通常のGCの一環で管理されていることである。 これは処理系製作が楽になること、将来世代GCなどより効率的な メモリ管理方式をKLICが採用するときに整合性が良いことが期待できること、といった ことを念頭に置いての設計である。
Copying GCであることからわかるように、ヒープは同じサイズのものが2面 存在する。片方が一杯になったらもう一方にコピーをして利用面を切りかえる。
各面のヒープの利用状況を図2.9に記述する。
「通常のヒープ」はアドレス下位側から連続的に割付を行う。 heap_limit に達するとヒープは一杯になったこととする。
「ヒープ溢れ」の検査を割付の度に毎回行うことは、 頻繁にヒープ割付が行われるKL1の実装としては速度、命令サイズの上で不利である。 そこで、この検査はKL1のリダクションの際に行うことにしている。 このため、heap_limit の先に常に一定語数の「余裕」がヒープにあるように 管理し、検査と検査の間にこの語数以下の割付しか行われないことを原則とすることに より、チェックの手間の軽減を計っている。
一方、通常のヒープに割付を行うためには、ヒープ割付点の値を知り、 変更できる必要がある。このヒープ先頭のアクセスを高速にするために、 この変数はレジスタに載せられることを期待して局所変数として持つこととし、 できるだけ大域変数にアクセスすることを避けたい。 よって、naiveにはこの局所変数にのっているヒープ割付点の値を ヒープ割付を行う可能性のある全関数に引数として渡し、 戻り値として返させる必要がある。しかしながら、C言語の仕様として 戻り値として返すことができる値は1つであること、 ヒープ割付をする「可能性」はあっても、実際に割付を行う頻度は低い関数が多いこと より、例外的に割付を行うような関数にはこのヒープ割付点を渡さず、 アドレス上位にある「システムヒープ」からメモリ割付を行うようにしている。 このシステムヒープはアドレス上位より順に割り付けられる。 システムヒープの割付を行ったら、それと同等の分だけheap limitを アドレス低位側に変更し、システムヒープとしては「常に余裕」があるように して利用する。
GCを行うと、すべてのアクティブセル(その時点で 有効であるデータセル)はシステムヒープにあったものも含め 新面の通常のヒープ側にコピーされ、 GC終了時には新面のシステムヒープは空の状況になっている。
また、KLICではヒープのサイズは動的に変更されるようになっている。 すなわち、GCをしても、ある一定の比率以上アクティブセルが 存在するような場合には、ヒープを確保しなおし、ヒープを拡大する、 という機構を備えている(この機構が動作することを禁止することも、 実行時ファイルの起動時に指定できる)。
各々のheap面についての値は、前述のglobal_variables に設定されている。 すなわち、以下の通りである。
