ガベージコレクターはどのようにスタックオーバーフローを回避しますか？

それで、ガベージコレクターがどのように機能するかを考えていて、興味深い問題を考えました。おそらく、ガベージコレクターはすべての構造を同じ方法で走査する必要があります。彼らは、リンクリストやバランスの取れたツリーなどを横断している天気を知ることができません。また、検索でメモリを使い果たすこともできません。1つの可能な方法、およびALL構造をトラバースする唯一の方法は、バイナリツリーの場合と同じようにすべて再帰的にトラバースすることです。ただし、これにより、リンクリストまたは単にバランスの悪いバイナリツリーでスタックオーバーフローが発生します。しかし、私が今まで使用したガベージコレクション言語はすべて、このようなケースに対処するのに問題がないようです。

ドラゴンブックでは、「スキャンされていない」種類のキューを使用しています。基本的に、構造を再帰的にトラバースするのではなく、キューとしてマークする必要があるものを追加し、最後にマークされていないものごとに削除します。しかし、このキューは非常に大きくなりませんか？

それでは、ガベージコレクタはどのように任意の構造をトラバースしますか？このトラバーサル技術はどのようにオーバーフローを回避しますか？

私はガベージコレクションの専門家ではないことに注意してください。この回答では、テクニックの例を示しています。ガベージコレクション手法の代表的な概要であるとは主張しません。

スキャンされていないキューが一般的な選択肢です。キューは大きくなる可能性があります-最も深いデータ構造と同じくらい大きくなる可能性があります。キューは通常、ガベージコレクションスレッドのスタックではなく、明示的に保存されます。

ノードの子の1つを除いてすべてがスキャンされると、ノードはスキャンされていないキューから削除できます。これは基本的に末尾呼び出しの最適化です。ガベージコレクターには、ノードの最も深い子を最後にスキャンしようとするヒューリスティックを含めることができます。たとえば、LispのGC carは、のcons前にをスキャンする必要がありcdrます。

スキャンされていないキューを保持しないようにする1つの方法は、ポインターを所定の位置に変更して、子が一時的に親を指すようにすることです。これは、ガベージコレクター以外のコンテキストで使用される定数メモリツリートラバーサル手法です。この手法の欠点は、GCがデータ構造を走査している間、データ構造が無効になるため、GCが世界を停止する必要があることです。これは取り決めのブレイクではありません。多くのガベージコレクターは、結果としてガベージを見逃すことはできても、見逃すことができるフェーズに加えて、世界を停止するフェーズを含んでいます。

一言で言えば：ガベージコレクタは、再帰を使用しないでください。これらは、本質的に2つのセット（組み合わせ可能）を追跡することにより、トレースを制御するだけです。トレースとセル処理の順序は関係ないため、実装をかなり自由に表現できます。したがって、実際にはメモリ使用量が非常に少ない多くのソリューションがあります。これは、ヒープがメモリ不足になると正確に呼び出されるため、不可欠です。新しいページを簡単に割り当てることができるため、大きな仮想メモリでは状況が少し異なります。そして、その大敵はスペースの不足ではなく、データの局所性の欠如 です。

質問が当てはまらない参照カウントではなく、ガベージコレクターのトレースを検討していると思います。

$U$$V$

最初に注意することは、すべてのトレースGCは、プログラムからアクセス可能なメモリ内のセルの有向グラフの体系的な調査に基づいた同じ抽象モデルに従うことです。メモリセルは頂点であり、ポインタは有向エッジです。そのために次のセットを使用します。

• $V$$V$$V=U\cup T$

• $U$

• $T$

• $H$

$V$$U$$U$$T$

$U$$V$

$U$$c$$V$$U$$c$$U$$T$

$U$$U$$V=T$$V$$H-V$$V$

$V$$U$$U$$T$

また、セルとは何か、1つまたは複数のサイズであるかどうか、それらの中でポインターを見つける方法、それらを圧縮する方法、およびガベージコレクションに関する書籍や調査で見つけることができる他の多くの技術的な問題に関する詳細はスキップします。

$U$

既知の実装が異なるのは、これらのセットが実際に表現される方法です。多くの手法が実際に使用されています：

• ビットマップ：各メモリセルに1ビットのマップ用に一部のメモリ空間が保持されます。これは、セルのアドレスを使用して見つけることができます。ビットは、対応するセルがマップで定義されたセットにあるときにオンになります。ビットマップのみを使用する場合、セルごとに2ビットのみが必要です。

• または、各セルにマークするための特別なタグビット（または2）のスペースがあります。

• $\log_2 p$$p$

• セルのコンテンツとそのポインターで述語をテストできます。

• 表示されているセットに属するすべてのセルのみを対象としたメモリの空き部分にセルを再配置できます。

• $V$$T$$T$$U$

• 単一のセットであっても、これらの手法を実際に組み合わせることができます。

前述のように、上記のすべては、実装されているガベージコレクターによって使用されていますが、奇妙に思えるかもしれません。それはすべて、実装のさまざまな制約に依存します。また、メモリ使用量がかなり安くなる可能性があります。最終結果には関係ないため、その目的のために自由に選択できる処理順序ポリシーが役立つ可能性があります。

新しい領域にセルを転送する、最も奇妙なものと思われるものは、実際には非常に一般的です。それはコピーコレクションと呼ばれます。ほとんどの場合、仮想メモリで使用されます。

明らかに再帰はなく、ミューテーターアルゴリズムスタックを使用する必要はありません。

もう1つの重要な点は、多くの最新のGCが大きな仮想メモリ用に実装されていることです。その後、新しいページを簡単に割り当てることができるため、実装するスペースと余分なリストまたはスタックを確保することは問題になりません。しかし、大きな仮想記憶では、敵はスペースの不足ではなく、場所の不足です。次に、セットを表す構造とその使用は、データ構造とGC実行の局所性を維持するように調整する必要があります。問題はスペースではなく時間です。不適切な実装は、メモリオーバーフローよりも許容できない速度低下を示す可能性が高くなります。

これらの手法のさまざまな組み合わせに起因する多くの特定のアルゴリズムについては言及しませんでした。

スタックオーバーフローを回避する標準的な方法は、明示的なスタックを使用することです（ヒープにデータ構造として格納されます）。それはこれらの目的にも有効です。ガベージコレクターは、多くの場合、調査/トラバースする必要があるアイテムのワークリストを持ち、これがこの役割を果たします。たとえば、「未スキャン」キューは、まさにこの種のパターンの例です。キューは大きくなる可能性がありますが、スタックセグメントに格納されないため、スタックオーバーフローは発生しません。いずれにしても、ヒープ内のライブオブジェクトの数よりも大きくなることはありません。

ガベージコレクションの「古典的な」説明（例：マークウィルソン、「ユニプロセッサガベージコレクションテクニック」、メモリ管理に関する国際ワークショップ、1992、（代替リンク）、またはAndrew AppelのModern Compiler Implementation（Cambridge University Press、 1998））、コレクターは「Mark and Sweep」または「Copying」に分類されます。

マークコレクターとスイープコレクターは、@ Gillesの回答で説明されているように、ポインター反転を使用して余分なスペースを必要としません。Appelは、Knuthがポインター反転アルゴリズムをPeter Deutsch、およびHerbert SchorrとWM Waiteに帰していると言います。

コピーガベージコレクターは、Cheyneyのアルゴリズムと呼ばれるものを使用して、余分なスペースを必要とせずにキュートラバーサルを実行します。このアルゴリズムは、CJ Cheyney、「非再帰的リスト圧縮アルゴリズム」、Commで導入されました。ACM、13（11）：677-678、1970。

コピーガベージコレクタには、from-spaceと呼ばれる収集しようとしているメモリのチャンクと、to-spaceと呼ばれるコピーに使用しているメモリのチャンクがあります。scanコピー先スペースは、コピーされたがスキャンされていない最も古いレコードをfree指すポインターと、コピー先スペースの次の空き位置を指すポインターを持つキューとして編成されます。ウィルソンの論文からのこの写真は次のとおりです。

to-spaceの各項目をスキャンすると、from-spaceの子freeをto-spaceのポインターにコピーしてから、from-spaceの子へのポインターをto-spaceの子の新しいコピーに変更します。データ構造がツリーではない場合（子が複数の親を持つことができる場合）に使用する必要がある余分なトリックがあります。その場合、子をfrom-spaceからto-spaceにコピーするとき、古いバージョンの子を、子の新しいコピーへの転送ポインターで上書きする必要があります。その後、古いバージョンの子への別のポインターをスキャンすると、すでにコピーされていることに気付き、再度コピーしないでください。