問題タブ [mark-and-sweep]

クラスを定義する ruby​​ エクステンションを書いています。Data_Wrap_Struct()のコールバックを実装するために使用する場合rb_define_alloc_func()、インスタンス変数を手動でマークして解放する必要がありますか? それとも、それはまだ私のために処理されていますか?

Java6でConcurrentMark＆Sweepを実行すると、「時間の関係でアボートプレクリーン」が発生します。これはどういう意味ですか？GCは実際の作業を行う前に、本当に途中で停止していますか？

私は参照カウンターのテクニックは知っていますが、マークスイープのテクニックについては、今日「プログラミング言語の概念」という本を読んで初めて知りました。
本によると：

ガベージ コレクションの元のマーク スイープ プロセスは、次のように動作します。ランタイム システムは、要求に応じてストレージ セルを割り当て、必要に応じてセルからポインターを切断します。ストレージの再利用 (ガベージの蓄積を許可する) に関係なく、使用可能なすべてのセルが割り当てられるまで続けます。この時点で、マーク スイープ プロセスが開始され、ヒープ内に残っているすべてのガベージが収集されます。プロセスを容易にするために、すべてのヒープ セルには、収集アルゴリズムで使用される追加のインジケーター ビットまたはフィールドがあります。

私の限られた理解では、C++ ライブラリのスマート ポインターは参照カウント手法を使用しています。この種のスマート ポインターの実装を使用する C++ のライブラリはあるのでしょうか。また、この本は純粋に理論的なものであるため、実装がどのように行われるかを視覚化することはできませんでした. このアイデアを示す例は非常に価値があります。私が間違っている場合は、私を修正してください。

ありがとう、

stop-the-world GC を使用し、メソッドで何らかの処理を行ったfinalize()場合、すべてのスレッドが中断され、やりたいことを何でも実行でき、GC スレッドを除いてリソースをめぐって競合するスレッドはないと想定できますか?

私はかつて、プログラミング言語の実装を試みている理想主義的でありながら「怠惰な」プログラマーの間で共通の考えについてどこかで読んだことがあります。次のとおりでした。

「わかっています。実装が簡単で書きやすい参照カウント GCer を作成し、時間ができたら実際の G​​Cer として再実装します。」

当然、この再実装は決して発生しません。

しかし、なぜそのような再実装が必要なのか疑問に思います。Perl 5 や Python などの言語で採用されているとされる時代遅れのアプローチよりも、インクリメンタルおよびコンカレントのさまざまなマーク アンド スイープ コレクターが優れていると見なされるのはなぜですか? (はい、Python がマーク アンド スイープ コレクターを使用してこのアプローチを強化していることは承知しています。)

循環参照は、このような議論の最初のトピックです。はい、それは面倒な場合があります (Perl の再帰的な coderef を参照し、複数の割り当てと参照の弱体化を含むように修正してください)。

しかし、代替手段はより良いですか？細かい実装の詳細については永遠に議論できますが、実際には、ほとんどのマークアンドスイープ GC 実装には次の問題があります。

• リソースが非決定論的に破壊され、推論が困難で冗長すぎるコードにつながります (.NET の IDispose や、他の多くの言語の try/finally 置換を参照してください)。
• 短命、長命、およびその間のすべてのさまざまなカテゴリのガベージによる追加の複雑さ。このような複雑さは、妥当なパフォーマンスに必要なように見えます。
• 別のスレッドが必要になるか、収集を実行するためにプログラムの実行を定期的に停止する必要があります。

弱い参照で軽減できる参照カウントの問題を修正するために、マークアンドスイープの失敗は正当化されますか?

私が取り組んでいる単純なスクリプト言語 API でマーク アンド スイープ ガベージ コレクションを実装しており、ガベージ コレクションのさまざまな実装について読んでいます。Lua などの API は、ホワイト リスト、グレー リスト、ブラック リストでマーク アンド スイープを使用します。

問題は、なぜそのようなリストがあり、なぜこれらの特定の色に入れられるのかについての説明が見つからないように見えることです.

私の現在の些細な実装では、単純に「死んだ」または「生きている」状態を使用しています。スイープでは、死んだオブジェクトが削除されます。私はネイティブ ヒープを使用しているため、GC 内での移動は行っていません。

Cで書いています。

私は、学習経験と高校卒業時の履歴書の両方のために、最近の週末に独自のスクリプト言語を書き始めました。基本的な型 (null、boolean、number、および string) で変数を解析し、演算子の優先順位を使用して数式を解析し、基本的なマークとスイープ ガベージ コレクターを配置できます (マーク/スイープ コレクターの完了後)。世代別ガベージ コレクタを実装します。ナイーブ マーク/スイープはあまり高速ではないことはわかっています)。ただし、ガベージ コレクターの参照オブジェクトを格納する方法がわかりません。今のところ、メモリへのポインタとマークされているかどうかを格納するクラス GCObject があります。リンクされたリストをそれに保存する必要がありますか ' クラス内のオブジェクトを参照していますか? 私は他の言語のガベージ コレクターを見てきましたが、GCObject ごとの参照のリンクされたリストが表示されないため、混乱しています。

TLDR: 他のオブジェクトによって参照されるオブジェクトをマーク アンド スイープ ガベージ コレクタに格納するにはどうすればよいですか? オブジェクトのリンクされたリストをすべての GCObjects に保存するだけですか?

みんなありがとう。

使用中のオブジェクトの時期尚早なガベージ コレクションを回避するために、Ruby 拡張機能でVALUEasを宣言することが適切な場合についてのドキュメントはあまり見つかりません。volatile

これが私がこれまでに学んだことです。空欄を埋められる人はいますか？

を使用する必要がないvolatile場合:

• C++ オブジェクト メンバー内 (スタック上にないため? )
• Ruby API を呼び出さない C/C++ メソッド内 ( Ruby API が呼び出されるまで GC がオンにならないため)

いつ使用する必要がありますvolatile か

• ALLOCRubyまたはmallocマクロ/関数のいずれかを呼び出す C/C++ メソッド内(これらは、メモリが高度に断片化されている場合に GC をトリガーする可能性があるため)
• Ruby 関数を呼び出す C/C++ メソッド (例: rb_funcall、rb_ary_newなど)

GC を回避するその他の方法

• VALUE使用中のマーク
• オブジェクトの作成中に GC を無効にしてから再度有効にする
• Ruby の割り当て方法を使用しない (危険)

すべて正しいですか？不足している詳細は何ですか? マーキング以外にvolatile方法はありますか？

私は単純なスクリプト言語に取り組んでおり、ガベージ コレクターのしくみを理解するのに助けが必要です。私が理解している限り、ガベージコレクターには2つのことがあります。

1. オブジェクト プール - 割り当てられたすべてのオブジェクトが含まれ、単純な配列として表すことができます。VM がオブジェクト (Number、String など) を作成すると、適切なインスタンスが作成され、オブジェクト プールにプッシュされます。

   /li>

2. フレーム (正しい用語かどうかは不明) - objectPool 内のオブジェクトへの参照が含まれています。変数を作成してそれに値を割り当てると、VM はフレームにエントリを作成します。変数値を取得する必要がある場合は、フレーム内で確認します。フレームはハッシュ マップとして表すことができます。

   /li>

ガベージ コレクション (少なくともマーク & スイープの実装) には、次の 2 つの手順が含まれます。

1. マーク: フレームに含まれるオブジェクトをウォークスルーし、それらをマークします。

   /li>

2. スイープ: objectPool に含まれるオブジェクトをウォークスルーし、マークされていないオブジェクトをすべて削除 (解放) します。

   /li>

何か不足していますか？これはすべて正しいように見えますか?

私はビデオGoogle IO 2008 - Dalvik Virtual Machine Internalsを見ていました. オブジェクトと一緒にマークビット（オブジェクトがガベージコレクションを実行できるかどうかを示すビット）を持つJVMとは対照的に、Androidはオブジェクトに関するガベージ情報に別のメモリを使用することがわかりました。

マークビット用に別のメモリを持ち、マークビット用に別のメモリを持たないことの利点と欠点を詳しく教えてください。

動画を見てもこの違いはわかりませんでした。