ぎこちなくではありますが、GCとして動作するライブラリがほぼ出来上がりました。あとは、セーフティで安全にABユーザーの皆様にメモリ管理を行ってもらえるよう、下記のような点に重点を合わせて作業を進めていこうと思います。

  1. 既存ソースコードの互換性を最重要視
  2. 保守的GCとしてGC管理外のメモリ空間も検査対象とする（malloc/freeとの混在が可能）
  3. GCを考慮することによる各種ライブラリモジュールの速度低下を防ぐ

1番目、まずはGCを使わない今までのソースコードが完全にコンパイル・実行できるようにします。GCを利用するしないはプログラマー次第ということになります。

2番目は1番目と言っていることが近いのですが、ようは今までmalloc/freeを使ったスタイルは問題なく動作するのは勿論のこと、mallocで確保されたメモリ空間もGC発動時の検査対象にすることでメモリの不正回収を回避することを意味します（mallocで確保されたメモリ上にGC_mallocで確保したメモリが参照されているにも関わらず、回収されてしまう問題が無くなります）。

過去のソースコードとの互換性を保ちながら、新しいコーディング手法としてGCを取り入れることが可能になります。

3番目は速度の問題です。基本ライブラリに組み込まれる利用頻度が高いモジュールでは、必ずしも内部処理をGCに頼る必要性はありません。例えば、Stringクラスのメモリ管理をGCでしてしまうと、利用する文字列バッファすべてがGC発動時の検査対象としてオーバーヘッドを生じさせてしまうなどの速度的な弊害が生じます。

GCと切り離して考えることができる基本ライブラリにおいては、GCとは無関係なメモリ空間を別途に用意し、速度低下を阻止します。

これが済んだら、正式にGCのリファレンスでも書いてみようと思います。3番目の別口メモリ空間に対するmalloc/freeに関しては、メモリ操作ライブラリの拡張が必要なので、ライブラリ開発フォーラムで仕様を提案したいと思います。