Cの真にポータブルなガベージコレクターを作成するのが難しいのはなぜですか？
Python C拡張機能を記述するためのドキュメント を読むと、CPythonのガベージコレクション戦略に関する部分に次のテキストが見つかります（強調は私のものです）：
... [自動ガベージコレクション]の欠点は、Cの、真にポータブルな自動ガベージコレクタがない一方で、参照カウントを移植可能に実装できることです。 （関数malloc（）およびfree（）が使用可能である限り、C標準はこれを保証します）。いつかCで十分にポータブルな自動ガベージコレクターが利用できるようになるかもしれません。それまでは、参照カウントを使用する必要があります。
強調された声明における著者の意図は正確には何ですか？確かに、少なくとも手元にある特定のVMに対しては、malloc、free、および基本的なデータ構造のみを使用して、ポータブルトレーシングGCを簡単に実装できます。
私は、作者が「移動GC」（実際にはそれが何であるかわからない）などのより高度なGC戦略を参照していると思います（私が間違っている場合は修正してください）。
もしそうなら-作者が正しいと仮定して、ポータブルな高度なガベージコレクタを作成することが難しい理由を説明してください。
ガベージコレクションでは、メモリ内で使用されなくなったオブジェクトを見つける可能性が必要です。これを行う1つの方法は、すべてのアクティブな参照を通過する マーキングアルゴリズム を使用することです。別の方法は、信頼できる 参照カウント を使用することです。
あなたの記事が示すように、Cでいくつかの参照カウント機能を実装することは確かに簡単です。しかし、標準Cでは、参照カウントが確実に実行されることを保証するものはありません。
- すべてのポインタ割り当てには参照カウントが必要になる可能性があります
- ポインターが使用されなくなったり、必要がなくなったりすると、参照の減分が必要になる可能性があります。
Cセマンティクスには、ガベージコレクションを可能にするいくつかのルールもありません。例えば：
- ポインタ演算により、効率的なマーキングアルゴリズムを使用することが非常に困難になります。コンパイラが役立つ場合でも、単一のオブジェクトをマークするだけでなく、メモリ範囲の使用を追跡する必要があります。
- キャストを使用すると、割り当てられたメモリの任意の場所が実行時にポインタに変換され、適切なマーキングを保証できなくなります。
- 効率の問題に追加するには、すべてのポインターに対して生成されたコードは、GCなしのスタックメモリへのポインターとGC付きのヒープへのポインターのケースを処理する必要があります。これは、コンパイラビルダーが準備ができていない大きなオーバーヘッドになります。
- セマンティクスは、メモリが解放される前に実行するクリーニングアクティビティを定義する必要があります（参照カウントの単純なケースにも適用されます）。
前提条件は標準のC言語機能では満たすことができないため、ライブラリに標準のGC機能を作成しようとした人はいません。
したがって、GC with Cのすべての実装は、善意に依存しています。たとえば、Macintoshの初期（90年代前半）には、OSのメモリ管理に依存する Cコンパイラ があったことを覚えています 移動ブロックも使用 移動ガベージコレクタのように。しかし、割り当てられたメモリを繰り返し処理するためにポインタ演算を使用する場合、メモリが中間に移動しないように、最初にシステムに通知する必要がありました（HLock/HUnlock）。そしてもちろん、それは完全に標準的ではありませんでした（そしてエラーが起こりやすい）.
一部の人々は、C言語を拡張して、参照カウントに必要な種類の欠けている規律を追加しようとしました。 1人の男が成功し、C++をもたらしました。 C++では、オブジェクトが使用されなくなったときに自動的に破棄される、参照カウントスマートポインターがあります。標準ライブラリ。しかし、これはガベージコレクションの非常に単純な形式です。他の場所で使用されていない、互いを参照しているオブジェクトのグループを識別するものはありません。まだマーク＆スイープガベージコレクターにはほど遠いです。
FYI：移動するGCは、連続する空きブロックのサイズを増やす（デフラグ）ために、連続していない使用済みメモリブロックを移動するGCです。 Cではポインタも更新する必要があるため、これにより複雑さがある程度追加されます。 GC言語では、GCで更新できるオブジェクト参照を介してオブジェクトに直接アクセスするため、移動は問題になりません。