低ポーズGCの背後にあるアルゴリズムは何ですか？

いくつかの言語は、javaの例のために、低休止GCを導入しました。

これらのGCは、全世界を一時停止することなく、ほとんどの作業を実行できます。これは明らかに非常に難しい問題です。スレッドが変更しているときにメモリを分析する必要があるため、プロセスの開始時に使用でき、終了時には使用できなくなったデータや、ゴミのように見えるデータ参照はメモリ内で移動され、GCが探している場所には表示されませんでした。

基本的に、その背後にあるアルゴリズムは何ですか？

このトピックは本当に技術的であるため、研究論文または本当に技術的な記事のリンクは有効な回答と見なされます。

基本的に、その背後にあるアルゴリズムは何ですか？

基本的には、マークアンドスイープアルゴリズムであり、別個のスレッドで「ちょうど」同時に実行されます。

その主題に関する研究論文に関して：

• ファイングレイン同期のない非常に同時のマークおよびスイープガベージコレクション

• 同時マークスイープガーベイブコレクター（2つの論文へのリンクが含まれています。1つは以下にリストされています）

• Java用のオンザフライガベージコレクターの実装

• マルチプロセッサシステム用のポータブルで控えめなガベージコレクション（Doligez Leroy、Powerpoint Presentation）

• オンザフライガベージコレクション：協力の演習（Edsger Wybe Djikstra作）

私の知る限り、Java G1ガベージコレクターはいわゆるヒープ領域を使用して、全世界の一時停止を回避しています。私が見る方法は、クリーンアップを実行するGCによって領域の1つがロックされている間、メモリ割り当ては別の領域で行われます。

ジェレミー・マンソンの説明を次に示します。

原理は簡単です。コレクターはヒープを固定サイズの領域に分割し、それらの領域のライブデータを追跡します。ポインターのセット（「記憶されたセット」）を領域に出し入れします。GCが必要であると判断されると、最初にライブデータの少ない領域が収集されます（つまり、「ガベージファースト」）。多くの場合、これは1つのステップで領域全体を収集することを意味します。領域へのポインタの数がゼロの場合、その領域をマークまたはスイープする必要はありません...

• Sunのエンジニアが設計を説明するテクニカルペーパー：Garbage-First Garbage Collection

IBMのリアルタイムJVMは、メトロノームと呼ばれるガベージコレクターを使用します。これは、GCアクティビティを個別のクォンタムに分割し、アプリケーション処理とインターリーブします。したがって、基本的には、定期的な（および非決定的な）世界停止GCが一時停止する代わりに、GCが並行して実行されている間、アプリケーションの実行速度が若干遅くなります。

動的な最適化を行い、ハードリアルタイムの要件を満たしている別のGCがありますが、見つけることができる唯一の参照はここにあります（ACMメンバーシップが必要です）。

興味深い同時リアルタイムガベージコレクターはstoplessです。従来のマークアンドスイープアプローチを使用しますが、マルチプロセッサシステムで使用するように設計されており、ロックフリーの並行マルチスレッドをサポートしています。

これが機能する理由は、JavaではGCのみがGC参照を含むメモリを解放できるためです。つまり、別のスレッドでオブジェクトを安全に読み取ることができる限り、スタック上の参照を監視するためにプログラムを一時停止するだけで済みます。

突然変異については、何らかの形でコピーオンライトを実装して、変更についてGCに通知することをお勧めします。