[C#] デリゲートをGCの対象から外す方法

（いつのまにか「何が」固定されているのか、に流れてしまいましたが）

それに関して、少なくともマネージ側でデリゲートインスタンスの参照が有効な間は、常にデリゲートに渡されたメソッドを呼び出すはず、というのが僕の主張です。

（なので、元質問者の人が書いているような状況は本来は起きないはずで、起きているとしたら何か原因があるはず）

渋木宏明(ひどり)さんの書き込み (2007-01-26 10:01) より:
で、元々このスレッドで問題にしていたコトは、アンマネージ側に渡ったコールバックアドレスがいつまで有効なのか？ということだったはずです。

Tdnr_Symさんの書き込み (2007-01-26 13:21) より:

引用:
渋木宏明(ひどり)さんの書き込み (2007-01-26 10:01) より: で、元々このスレッドで問題にしていたコトは、アンマネージ側に渡ったコールバックアドレスがいつまで有効なのか？ということだったはずです。

よく分からないですが、私の予想では
クラス・アセンブリ・AppDomainがアンロードされるまでは有効な気がします。

よく分からないですが、私の予想では
クラス・アセンブリ・AppDomainがアンロードされるまでは有効な気がします。

ではメソッド本体はメモリのどの部分に配置されるでしょう。
Intel CPUの場合で考えますと

・JITコンパイルずみのネイティブコードは、
　CS：コードセグメント（セレクタが示すGDT/LDTで示される）領域にあるはずです。
・スタック領域に配置されたデータは
　SS：スタックセグメントの領域にあるでしょう。
・ヒープ領域に配置されたデータは、おそらく
　DS：データセグメントで示される場所にあると思います。

…という風に、
オブジェクトといってもデータとメソッドはメモリ上の別々の領域にあるはずです。

なちゃさんの書き込み (2007-01-26 13:53) より:

前に挙げた、
http://msdn.microsoft.com/msdnmag/issues/06/05/bugbash/default.aspx#S3
を見ると、デリゲートがGCで回数されるまで、と思われます。

when the delegate is no longer needed by managed code, the garbage collector is free to reclaim it (reclaiming the delegate causes the associated thunk to be freed as well), which will result in the function pointer in unmanaged code becoming invalid

シャノンさんの書き込み (2007-01-26 14:06) より:
すべてのセグメントが、単一の広大なメモリ空間を指し示すような実装がありふれていることを考えれば、

スタックもコードも移動しない保証はない気が。

スレッドごとにスタック領域を持っているのは分かりますが、
１プロセスの開始から終了までの間に、
スタックやコードの領域が移動することってあるのでしょうか？

渋木宏明(ひどり)さんの書き込み (2007-01-26 14:49) より:
＊１ マネージスレッドはＯＳのスレッドそのものではないし、yield なんかの存在を見ると、スタックに関しては「移動」するかどうかはともかく、積極的に管理する（したい）方向なのかな、と。