1

大きなオブジェクトにはIDisposalパターンを使用することをお勧めしますが、オブジェクトが「大きい」と見なされる制限を決定する信頼できる方法がないように見えるのはなぜでしょうか?

内部的には、LOH で割り当てられるオブジェクトの下限というような区別が存在します。それが 85k として公に伝えられるときはいつでも、同時に 1 つはその数に依存することを妨げられます。

特に、多くの「より大きな」配列を処理するアプリケーションの場合、適切なメモリ管理を実装し、LOH の断片化を防ぐために、その制限が必然的に必要になります。一方、「より小さい」配列の場合、IDisposal はメモリ消費の観点からは意味がありません。ここでは、圧縮 GC の方がはるかに優れています。

なんでそんなことないの

GC.GetLOHLimit()

またはさらに良い：

bool GC.ArrayTargetForManualDisposal(Type type, int length);

編集: IDisposable パターンは、特別なオブジェクト (「大きな」オブジェクトまたは管理されていないオブジェクト) を適切に処理するための推奨事項にすぎません。私の質問は、ランタイムによるこれらのオブジェクトの特別な処理があると仮定していません。むしろ、オブジェクトが特別なメモリ管理に従うべきかどうかを知るために、パターンの実装者 (他の人もそうかもしれません) にランタイム サポートを求めます。

4

2 に答える 2

4

IDisposableマネージドメモリ管理とは関係ありません。オブジェクトの破棄はユーザーの慣例\パターンであり、ランタイムによって内部的に使用されることはなく、メモリ管理には影響しません。ランタイムにはの知識がありませんIDisposable。の唯一の特別な処理/認識はIDisposable、キーワードとともに使用された場合ですusingが、これは、ランタイムではなく、コンパイラ（少なくともC＃コンパイラ）によって認識されます。

LOHに関しては、LOHアルゴリズムによる公的な保証はありません。そのため、そもそも最大オブジェクトサイズなどのパラメーターを取得するためのAPIはありません。CLRの将来のバージョンでは、LOHを考慮するためのオブジェクトサイズが実際に動的になる可能性があります。CLR設計者は、ユーザーがメモリ管理の内部の詳細に自分自身を結び付けることを望んでいません。これにより、既存の多くのプログラムを壊さずにメモリ管理を変更することが困難または不可能になるためです。

CLRのメモリ管理に関心がある場合は、まず、CLRに関係してIDisposableいないという事実を把握することをお勧めします。

于 2011-01-27T09:44:04.703 に答える
3

chibacity が言ったように、IDisposable は LOH 管理とは関係ありません。LOH に関する優れた記事: Large Object Heap Uncoveredがあります。

そうは言っても、私の知る限り、LOH サイズを決定するパブリック API はありません。SSCLI「ローター」で 85000 バイト制限への参照を見つけることができます(ソースはこちらから入手できます: Shared Source Common Language Infrastructure 2.0 Release Download ):

clr/src/vm/gc.h:

#define LARGE_OBJECT_SIZE   85000

このソースは CLR 4 ではなく CLR 2.0 と同等のソースですが、既存のコードに深い影響を与えることは確実であるため、これを変更したとは思いません。

したがって、この値を賢く使いたい場合は、おそらく安全に定数に入れるか、構成可能にすることができますが、実行中のプロセス中に動的に変更されることはありません。

于 2011-01-27T10:44:12.273 に答える