ガベージコレクションは、ネイティブにコンパイルされた言語でどのように機能しますか？

スタックオーバーフローに関するいくつかの回答を参照した後、ネイティブコンパイルされた言語の一部にガベージコレクションがあることが明らかです。しかし、これが正確にどのように機能するかは私には不明です。

ガベージコレクションがインタプリタ言語でどのように機能するかを理解しています。ガベージコレクターは、単にインタープリターと一緒に実行され、プログラムのメモリから未使用および到達不能なオブジェクトを削除します。両方が一緒に実行されています。

しかし、これはコンパイルされた言語でどのように機能しますか？私の理解では、コンパイラがソースコードをターゲットコード（特にネイティブマシンコード）にコンパイルすると、完了します。その仕事は終わりました。それでは、コンパイルされたプログラムをどのようにガベージコレクションするのでしょうか？

「ガベージ」オブジェクトを削除するためにプログラムが実行されている間、コンパイラは何らかの方法でCPUと連携しますか？または、コンパイラは、コンパイルされたプログラムの実行可能ファイルに最小限のガベージコレクタを含めますか。

Stack Overflowに関するこの回答からの抜粋により、後者のステートメントは前者よりも妥当性があると思います：

そのようなプログラミング言語の1つがEiffelです。ほとんどのEiffelコンパイラは、移植性の理由でCコードを生成します。このCコードは、標準Cコンパイラによってマシンコードを生成するために使用されます。Eiffel実装は、このコンパイルされたコードに対してGC（および場合によっては正確なGC）を提供します。VMは必要ありません。特に、VisualEiffelコンパイラーはネイティブのx86マシンコードをフルGCサポートで直接生成しました。

最後のステートメントは、プログラムの実行中にガベージコレクターとして機能するプログラムを最終的な実行可能ファイルにコンパイラが含めることを意味するようです。

ネイティブにコンパイルされ、オプションのガベージコレクタを備えたガベージコレクションに関するD言語のWebサイトのページも、ガベージコレクションを実装するために元の実行可能プログラムと一緒にバックグラウンドプログラムが実行されることを示唆しているようです。

Dは、ガベージコレクションをサポートするシステムプログラミング言語です。通常、メモリを明示的に解放する必要はありません。必要に応じて割り当てるだけで、ガベージコレクターはすべての未使用メモリを利用可能なメモリのプールに定期的に返します。

この方法は、上記の場合はされて使用され、どのように正確にそれが働くだろうか？コンパイラは、ガベージコレクションプログラムのコピーを保存し、生成する各実行可能ファイルに貼り付けますか？

または、私は私の考えに欠陥がありますか？その場合、コンパイルされた言語のガベージコレクションを実装するためにどのメソッドが使用され、どのように正確に機能しますか

コンパイルされた言語のガベージコレクションは、インタプリタ言語の場合と同じように機能します。Goのような言語は、通常コードが事前にマシンコードにコンパイルされている場合でも、トレースガベージコレクターを使用します。

（トレース）ガベージコレクションは通常、現在実行中のすべてのスレッドの呼び出しスタックをウォークすることから始まります。それらのスタック上のオブジェクトは常にライブです。その後、ガベージコレクターは、ライブオブジェクトグラフ全体が検出されるまで、ライブオブジェクトが指すすべてのオブジェクトを走査します。

これを行うには、Cなどの言語が提供しない追加情報が必要であることは明らかです。特に、すべてのポインター（およびおそらくそのデータ型）のオフセットを含む各関数のスタックフレームのマップ、および同じ情報を含むすべてのオブジェクトレイアウトのマップが必要です。

ただし、型保証が強い言語（たとえば、異なるデータ型へのポインターキャストが許可されていない場合）が、コンパイル時にそれらのマップを実際に計算できることは簡単にわかります。バイナリ内の命令アドレスとスタックフレームマップ間の関連付け、およびデータ型とオブジェクトレイアウトマップ間の関連付けを単に保存します。その後、この情報により、オブジェクトグラフトラバーサルを実行できます。

ガベージコレクター自体は、C標準ライブラリと同様に、プログラムにリンクされたライブラリにすぎません。たとえば、このライブラリはmalloc()、メモリの負荷が高い場合に収集アルゴリズムを実行するのと同様の機能を提供できます。

コンパイラは、ガベージコレクションプログラムのコピーを保存し、生成する各実行可能ファイルに貼り付けますか？

違法で奇妙に聞こえますが、はい。コンパイラには、ガベージコレクションコードだけでなく、ユーティリティライブラリ全体が含まれており、このライブラリへの呼び出しは、作成する各実行可能ファイルに挿入されます。これは実行時ライブラリと呼ばれ、通常それが提供するさまざまなタスクの数に驚くでしょう。

または、コンパイラはコンパイルされたプログラムのコードに最小限のガベージコレクターを含めますか。

これは、「コンパイラがプログラムをガベージコレクションを実行するライブラリにリンクする」という奇妙な言い方です。しかし、はい、それが起こっています。

これは特別なことではありません。コンパイラは通常、大量のライブラリをコンパイルするプログラムにリンクします。それ以外の場合、コンパイルされたプログラムは、多くのことをゼロから再実装しない限り、あまり実行できません。テキストを画面/ファイル/に書き込むことさえ、ライブラリを必要とします。

しかし、GCは、ユーザーが呼び出す明示的なAPIを提供するこれらの他のライブラリとは異なるのでしょうか？

いいえ：ほとんどの言語では、ランタイムライブラリは、GCを超えて、公開APIなしで多くの舞台裏作業を行います。次の3つの例を検討してください。

1. 例外の伝播とスタックのアンワインド/デストラクタの呼び出し。
2. 動的メモリ割り当て（通常は、ガベージコレクションがない場合でも、Cのように関数を呼び出すだけではありません）。
3. 動的な型情報の追跡（キャストなど）。

したがって、ガベージコレクションライブラリはまったく特別なものではなく、プログラムが事前にコンパイルされたかどうかにはアプリオリは関係ありません。

しかし、これはコンパイルされた言語でどのように機能しますか？

あなたの言葉遣いは間違っています。プログラミング言語はある仕様、いくつかの技術的な報告書に書かれた（良い例えば、参照R5RSを）。実際には、特定の言語実装（ソフトウェア）を参照しています。

^{（一部のプログラミング言語は仕様が間違っているか、欠落している場合や、サンプル実装に準拠している場合があります。それでも、プログラミング言語は動作を定義します -たとえば、構文とセマンティクスを持ちます - ソフトウェア製品ではありませんが、いくつかのソフトウェア製品によって実装されます;多くのプログラミング言語にはいくつかの実装があります;特に、「コンパイルされた」は実装に適用される形容詞です-たとえプログラミング言語がコンパイラよりもインタープリターによって実装されやすい場合でも）}

私の理解では、コンパイラがソースコードをターゲットコード、特にネイティブマシンコードにコンパイルすると、完了します。その仕事は終わりました。

インタープリターとコンパイラーは大まかな意味を持ち、一部の言語実装は両方であると見なされることに注意してください。つまり、間に連続性があります。最新読むドラゴンブックと考えるバイトコード、JITコンパイル、動的にコンパイルされたCコードを放出するいくつかの後、「プラグイン」のdlopen（3）同じプロセスで-ed（および現在のマシンでは、これと互換性があるために十分に高速でありますインタラクティブREPL、これを参照）

GCハンドブックを読むことを強くお勧めします。答えるには本全体が必要です。その前に、ガベージコレクション wikiページを読んでください（以下を読む前に読んでいると思います）。

コンパイルされた言語実装のランタイムシステムにはガベージコレクターが含まれており、コンパイラはその特定のランタイムシステムに適合するコードを生成しています。特に、割り当てプリミティブ（マシンコードにコンパイルされる）は、ランタイムシステムを呼び出します（または呼び出します）。

それでは、コンパイルされたプログラムをどのようにガベージコレクションするのでしょうか？

ランタイムシステムを使用する（そして「フレンドリー」で「互換性がある」）マシンコードを出力するだけです。

あなたは特に、いくつかのガベージコレクションライブラリを見つけることができることに注意してくださいベームGC、RavenbrookのMPS、あるいは私の（メンテナンスされていない）Qish。また、単純な GCのコーディングはそれほど難しくありません（ただし、デバッグは難しく、競合する GCのコーディングは困難です）。

場合によっては、コンパイラは保守的な GC（Boehm GCなど）を使用します。次に、コーディングすることはあまりありません。保守的なGCは（コンパイラがその割り当てルーチンまたはGCルーチン全体を呼び出すとき）コールスタック全体をスキャンし、コールスタックから（間接的に）アクセス可能なメモリゾーンがライブであると想定します。入力情報が失われるため、これは保守的な GC と呼ばれます。呼び出しスタック上の整数が偶然アドレスのように見える場合は、追跡されます。

他の（より困難な）場合、ランタイムは世代別コピーガベージコレクションを提供します（典型的な例は、Ocamlコンパイラーで、このようなGCを使用してOcamlコードをマシンコードにコンパイルします）。次に、問題は呼び出しスタックですべてのポインターを正確に見つけることであり、それらのいくつかはGCによって移動されます。次に、コンパイラーは、ランタイムが使用する呼び出しスタックフレームを記述するメタデータを生成します。そのため、呼び出し規約とABIは、その実装（つまりコンパイラ）とランタイムシステムに固有のものになりつつあります。

場合によっては、コンパイラーによって生成されたマシンコード（実際にはそれを指すクロージャーですら）自体がガベージコレクトされます。これは特に、すべてのREPLインタラクションに対してマシンコードを生成するSBCL（優れたCommon Lisp実装）の場合です。これには、コードとその内部で使用される呼び出しフレームを記述するメタデータも必要です。

コンパイラは、ガベージコレクションプログラムのコピーを保存し、生成する各実行可能ファイルに貼り付けますか？

並べ替え。しかし、ランタイムシステムは、時々 、（Linuxや他のいくつかのPOSIXシステムでは）それもに渡されたスクリプトインタプリタ、例えば可能性など、共有ライブラリ可能性（2）はexecveでシェバング。または、ELFインタープリター。elf（5）およびPT_INTERPなどを参照してください。

ところで、ガベージコレクション（およびそのランタイムシステム）を使用する言語のほとんどのコンパイラは、今日ではフリーソフトウェアです。したがって、ソースコードをダウンロードして調べてください。

すでにいくつかの良い答えがありますが、この質問の背後にあるいくつかの誤解を解消したいと思います。

それ自体は「ネイティブにコンパイルされた言語」のようなものはありません。たとえば、同じJavaコードが古い電話（Java Dalvik）で解釈され（実行時に部分的にジャストインタイムでコンパイルされ）、新しい電話（ART）で（前もって）コンパイルされます。

コードをネイティブで実行することと解釈することの違いは、見かけよりもはるかに厳密ではありません。両方とも、動作するためにいくつかのランタイムライブラリとオペレーティングシステムが必要です（*）。インタープリターコードにはインタープリターが必要ですが、インタープリターはランタイムの一部にすぎません。ただし、インタープリターを（ジャストインタイム）コンパイラーに置き換えることができるため、これでも厳密ではありません。最大のパフォーマンスを得るには、両方が必要な場合があります（デスクトップJavaランタイムには、インタープリターと2つのコンパイラーが含まれています）。

どのようにコードを実行しても、同じように動作するはずです。メモリの割り当てと解放は、ランタイムのタスクです（ファイルを開く、スレッドを開始するなど）。あなたの言語で、あなたはただ書くnew X()か似ています。言語仕様には何が起こるべきかが記述されており、ランタイムがそれを行います。

空きメモリの一部が割り当てられたり、コンストラクタが呼び出されたりします。十分なメモリがない場合、ガベージコレクタが呼び出されます。既にコードのネイティブな部分であるランタイムにいるので、インタープリターの存在はまったく問題ではありません。

コードの解釈とガベージコレクションの間には、実際には直接的な関係はありません。Cのような低レベル言語は、すべての速度ときめ細かな制御のために設計されているだけであり、非ネイティブコードやガベージコレクターの考えにはうまく合いません。したがって、相関関係があります。

これは、たとえばJavaインタープリターが非常に遅く、ガベージコレクターがかなり非効率的だった昔、非常に真実でした。今日、物事は大きく異なり、インタープリター言語について話すことは意味を失っています。

（*）少なくとも汎用コードについては、ブートローダーなどを残してください。

詳細は実装によって異なりますが、一般的には次のいくつかの組み合わせがあります。

• GCを含むランタイムライブラリ。これはメモリ割り当てを処理し、「GC_now」関数を含む他のいくつかのエントリポイントを持ちます。
• コンパイラは、GCのテーブルを作成して、どのデータ型のどのフィールドが参照されているかを認識します。これは、GCがスタックからトレースできるように、各関数のスタックフレームに対しても実行されます。
• GCがインクリメンタル（GCアクティビティがプログラムでインターリーブ）またはコンカレント（個別のスレッドで実行）の場合、コンパイラは参照が更新されたときにGCデータ構造を更新する特別なオブジェクトコードも含みます。この2つには、データの一貫性に関して同様の問題があります。

インクリメンタルGCとコンカレントGCでは、コンパイルされたコードとGCが協力して、不変条件を維持する必要があります。たとえば、コピーコレクターでは、GCはスペースAからスペースBにライブデータをコピーし、ゴミを残して動作します。次のサイクルでは、AとBを反転させて繰り返します。したがって、1つのルールは、ユーザープログラムがスペースAのオブジェクトを参照しようとするたびに、これが検出され、オブジェクトがすぐにスペースBにコピーされ、プログラムが引き続きアクセスできるようにすることです。転送アドレスがスペースAに残されて、GCにこれが発生したことを示し、オブジェクトへの他の参照がトレースされるときに更新されるようにします。これは「読み取りバリア」として知られています。

GCアルゴリズムは60年代から研究されており、このテーマに関する広範な文献があります。さらに情報が必要な場合はGoogle。