MonoのWebページで、BoehmGCを正確なモードで使用していることを読みました。私もC++でBoehmGCを使用していますが、ドキュメントやヘッダーには、正確なモードを示すものはなく、オンにする方法もありません。
それが実際にデフォルトで正確なモードを持っているかどうか、そしてそれをオンにする方法、またはそれがMono開発者によるある種の変更であったかどうかについての情報はありますか?
MonoのWebページで、BoehmGCを正確なモードで使用していることを読みました。私もC++でBoehmGCを使用していますが、ドキュメントやヘッダーには、正確なモードを示すものはなく、オンにする方法もありません。
それが実際にデフォルトで正確なモードを持っているかどうか、そしてそれをオンにする方法、またはそれがMono開発者によるある種の変更であったかどうかについての情報はありますか?
モノの下でのベームGCの正確なモードはただではありませんGC_MALLOC_ATOMIC
。これは、基本型の配列にのみ当てはまります。
管理対象タイプの場合は、GC_gcj_malloc
が使用されます。Monoのコンパイラは、すべてのマネージドタイプのオブジェクト記述子を生成し、GC_gcj_malloc
サイズの引数とマネージドタイプの記述子へのポインタを使用して呼び出すだけです。次に、Boehm GCは、マークフェーズ中に記述子を参照して、管理対象ポインターをトレースします。
最終的には、ルートポインタだけが生のポインタとしてスタックに配置されます(GC_gcj_malloc
void *を返し、GCが収集する前に、ある種のスタック記述子を介してポインタがスタック上のどこにあるかをGCに伝える方法はありません)。これが、Mono(SGenより前)がスタックを保守モードでスキャンすると言っている理由です。
これをC++で実装する場合は、C++コンパイラに依存してオブジェクト記述子を生成することはできません。私がずっと前に想像したのは、管理対象クラスとしてマークされたクラス定義のすべてのC ++ヘッダーファイルを解析し(たとえば_ref class MyManagedObject
、_ref
は単に#define
何もない)、それらのオブジェクト記述子を含むヘッダーファイルを生成する中間コンパイラを作成することでした。次に、C ++コンパイラがvtableを割り当てる方法を制御できないためではなく、 GC_make_descriptor
andGC_malloc_explicitly_typed
関数を使用してオブジェクトを正確なモードで割り当てます。GC_gcj_malloc
*編集:GCC用のマネージC ++(オープンソースGPL v3)を参照してください。
ガベージコレクター(ここにアーカイブ)からのファイルdoc / gcinterface.htmlは、次のように述べています。
void * GC_MALLOC_ATOMIC(size_t nbytes)nbytesのストレージを割り当てます。nbytesに比例する(償却された)時間が必要です。結果のオブジェクトは、参照されていない場合、自動的に割り当てが解除されます。クライアントは、結果のオブジェクトにポインターが含まれないことを約束します。メモリはクリアされません。これは、文字列、浮動小数点配列、ビットマップなどを割り当てるための推奨される方法です。ディストリビューションのgc_typed.hのインターフェイスを使用して、ポインターの場所に関するより正確な情報をコレクターに伝達できます。
使用できる「正確な」インターフェースがあるようです。
正確なモードでは、ポインターが格納されている場所を正確に示すために、コンパイラーからのサポートが必要だと思います。CおよびC++での型キャストは、これをほぼ不可能にします。
リフレクションが組み込まれたマネージド言語を使用すると、これがはるかに簡単になります。