Copyされたかどうかの判定

 

KLICでは構造体の内部を直接指すポインタを許しているため、 構造体全体がコピーされているのか、構造体の一部がコピーされているのかを 判断する方法は必ずしも自明ではない。

重複してコピーを行わないため、コピーされたかどうかを判定する必要がある。  

• ATOMICデータの場合には「旧領域にあるATOMICデータはコピーされていない」 という基準で判断する。

• 通常のREFは「旧領域を指している限りその先にはコピーされていないデータが ある」という判断で良い。

• CONSの場合、そのCDR部がCONSタグで新領域を指している場合には、 CAR/CDR共に新領域にコピー済みであるとする。CONSのコピーは、CONSタグを持った セルと2ワードセル同時に行うため、CONSタグのセルと2ワードセルがこのように 新旧領域に跨がることはないので特殊なマークとして利用できる。

• FUNCTORの場合、1ワード目がさらにFUNCTORタグであれば、それは新領域への コピー先であることを表わす。FUNCTORタグの先は、ATOMである(通常の 関数FUNCTOR)であるか、REFである(data object)以外には通常ありえないため、 特殊なマークとして利用できる。

• ゴールレコードの場合には、
  • エンキュー済みのゴールレコードの場合には、ゴールスタック をコピーすることにより 行われ、ゴールスタック同士でゴールレコードを共用することはないため、 重複コピーは なされない(中断構造中で発見しても、タグがREFであればすでに エンキューされているので、コピーしない(ページ、第2章参照))。

  • 中断ゴールは、コピーの後に、next fieldにコピー先へのポインタを入れる。 さらに、pred部に0を入れる。よって、中断ゴールで、pred部に0が入っているものは コピー済みである。さらに、ゼロが入っておらず、かつ、next fieldがREFであるものは すでにscheduleされたものであるので、中断ゴールとしてはcopy する必要がない (goal queueをコピーするときにコピー対象になる)。

• Consumer, generator objectでは、先頭のfieldが新領域へのポインタに なっていればそこがコピー先である(コピーされる前はこのfieldは メソッド表を指しており、これはヒープの外である)。