同様ハーゲンダッツのアイスクリーム、オブジェクト指向は、しかし、よりナッツやバナナで、多くの味で来ます。したがって、非常に一般的な用語で述べられた質問に答えることは危険です。特定のオブジェクト指向言語には、仮想メソッドで問題を引き起こす可能性のある予期しない機能が含まれている可能性があります。どのような機能が問題を引き起こす可能性があるかを想像しようとすることは、少し実りのない練習であると私は恐れています。正確な質問に答えてみてください。
タグフリーGCの基本原則は、いつでもスタックからメモリを検査し、ライブに割り当てられたメモリのすべてのチャンクの実際のタイプを知ることができることです(これは、GCが正確に必要とするものだからです)動作するように)。これは、関数またはメソッドの各呼び出しポイントで、スタック上またはヒープ上の呼び出し元の現在のアクティブ化ブロックの状態、つまりブロックの現在の変数と初期化の状態を知ることも意味します。必要な構造情報は、解釈されるデータ記述子として、または実行可能なgc-ルーチンとして保存できます。GCの効率を向上させます。タグフリーGCの重要な点は、この情報を静的に決定できることです。これにより、型またはクラスのインスタンスごと、または関数のアクティブ化ごとではなく、コードとともに一度に格納できます。ポリモーフィック型の場合のように、この情報が動的に変化する可能性がある場合は、動的呼び出しシーケンスを通じて静的型情報を追跡および合成することによって、その情報を計算できる必要があります。
メソッドが仮想であり、仮想テーブルを通じて呼び出されるという事実自体は問題ではありません。呼び出し元は、自身のアクティベーションレコードのGCに関して重要ではないため、呼び出し元を知る必要はありません。呼び出し先は、それ自体を認識し(コンパイラーがそれを参照)、必要な情報をすべて持っている必要があります。情報は、ポリモーフィズムの場合のように不完全な場合があり、呼び出しシーケンスで使用可能な他のタイプの情報から完成する必要があります。実際、MLのような言語では、関数をパラメーターとして渡したり、タプルに入れたりできるため、呼び出し元は、実際に呼び出している関数がわからない場合があります。
重要なのは、呼び出し中のコードのどこで呼び出し先が呼び出されるかを呼び出し元が知っているため、呼び出し中にアクティブ化ブロックの状態を判断できることです。これは静的に呼び出しポイントに依存しているため、呼び出し先の返信先アドレスから推測できます(さまざまな作成者が使用する技術的なバリエーションに応じてさまざまな方法で)。したがって、対応するものgc-routine
は、その戻りアドレスから何らかの方法で見つけることができます。たとえば、呼び出し直後のコードに含めることができますが、他の同等の手法を検討することもできます。したがって、呼び出し先がGCによって中断された場合、呼び出し元のアクティブ化レコードに対してGCを実行することができます。呼び出し元は呼び出し元に対してGC作業を行わず、自分のアクティベーションレコードに対してのみ行います。
問題になる可能性があるのは、(ポリモーフィズムの場合のように)呼び出し先に渡されるすべての値の実際のタイプを確実に知らせることです。より正確には、GCが発生したときにその情報を見つけることが可能でなければならず、仮想を介してアクセスする実際のメソッドのアクティブ化レコードを処理する必要があります。
この最後の問題をより正確にするかどうかは、OO言語の実際の機能とクラス/オブジェクト構造、その型編成に依存していると思います。
しかし、呼び出し元は呼び出し先を知る必要がないため、間接呼び出しが問題になる可能性があることはわかりません。
別のポイント(OPのコメントに答える)は、ここでの問題は、GCがコンパイルされたコードから実行されるか、記述子から解釈されるかではなく、型情報に動的タグが必要かどうかです。
提案:これに関するさらなる研究を見つけるには、お気に入りの検索エンジン(およびその他のWebリソース)を使用して、Goldbergの論文またはその主要な参考文献を引用している論文を探します。手順を再帰的に適用し、オブジェクト指向や仮想などのキーワードを追加します。