LinuxJournalで、Boehm-Demers-Weiserガベージコレクタライブラリに関する記事を読みました。自分の参照カウントの実装の代わりに、ライブラリで使用するのは興味深いことです。
質問が1つだけあります。共有ライブラリにのみgcを使用し、メインアプリケーションでmalloc / freeを使用することは可能ですか?gcがヒープをチェックする方法がよくわからないので、その場合のgcのパフォーマンスと起こりうる副作用について心配しています。
LinuxJournalで、Boehm-Demers-Weiserガベージコレクタライブラリに関する記事を読みました。自分の参照カウントの実装の代わりに、ライブラリで使用するのは興味深いことです。
質問が1つだけあります。共有ライブラリにのみgcを使用し、メインアプリケーションでmalloc / freeを使用することは可能ですか?gcがヒープをチェックする方法がよくわからないので、その場合のgcのパフォーマンスと起こりうる副作用について心配しています。
マニュアルの例は次のように述べています。
通常、ガベージコレクションされた割り当てをシステムと混合しないことが最善です
malloc
-free
。その場合、ガベージコレクションされたヒープへのポインタをシステムに割り当てられたメモリに格納しないように注意する必要がありますmalloc
。
より具体的にはC++の場合:
C ++の場合、コレクターによってトレースされない領域にガベージコレクションされたヒープへのポインターを格納しないように特に注意する必要があります。コレクターには、それを簡単にするためのいくつかの代替インターフェースが含まれています。
マニュアルのソースコードを見ると、ガベージコレクションされたメモリは特定の呼び出しによって処理されるため、管理は個別に(コレクターまたは手動で)処理されます。ライブラリがその内部を適切に処理し、収集されたメモリを公開しない限り、問題はありません。他のライブラリがどのようにメモリを管理しているかわからないので、それらを使用することもできますね。:)
はい、2つを組み合わせることができると思います。ただし、ガベージコレクションオブジェクトで割り当てるオブジェクトへの参照を保持する通常のアロケータでオブジェクトを割り当てると、その参照はGCに表示されないため、オブジェクトが時期尚早に割り当てを解除します。
収集されるべきではないメモリ内の参照をGCで考慮する必要がある場合は、GC_MALLOC_UNCOLLECTABLE関数の仕様を確認してください。
要約すると、はい、しかしあなたが注意しなければここにドラゴンがいます!