Утечки памяти MSIL - PullRequest
       6

Утечки памяти MSIL

1 голос
/ 30 сентября 2010

Мы используем пользовательский класс RuntimeDataBuilder , который динамически создает в памяти тип .NET с помощью Reflection.Emit для создания простых методов получения / установки свойств для информации, которую мы получаем из универсального сервиса данных WCF.Служба предоставляет структуру типа DataSet, состоящую из 1..m DataTableDefinitions, каждая из которых содержит 1..m DataTableColumnDefinitions.Когда информация принимается на стороне клиента, мы генерируем тип с его установщиками / получателями свойств, чтобы повысить производительность и упростить связывание с нашим клиентом Silverlight.Все это прекрасно работает.

Мой вопрос связан с возможной утечкой памяти, связанной с восстановлением типа.Время от времени пользователь может изменять параметры запроса, что может привести к тому, что по проводам будет поступать больше / меньше информации.Поэтому он лишает законной силы предыдущий тип, который мы создали, и я хочу убедиться, что мы можем освободить память, используемую этим предыдущим определением типа.Начиная с этой статьи о MSDN я понимаю, что если вы используете генерацию облегченного кода (LCG), то код выделяется в управляемой куче, которая будет возвращена GC, когда на нее ничего не будет ссылаться.Но LCG только кажется применимым к динамическим методам.Меня беспокоит тип со всеми его методами получения / установки свойств, который больше не требуется.Если это распределяется в неуправляемой куче, наша единственная надежда на восстановление памяти, похоже, состоит в том, чтобы убедиться, что тип загружен во временный домен приложений, который мы можем выгружать, когда он больше не требуется.

Может кто-нибудь пожалуйстаподтвердите или выделите другой способ восстановления памяти.

Thx

Ответы [ 2 ]

4 голосов
/ 01 октября 2010

Вы правы, полагая, что динамические типы останутся в памяти после загрузки в домен приложений. И, как вы говорите, единственный способ выгрузить их из процесса - это разместить их в отдельном домене приложений, который затем можно полностью выгрузить. Но вы должны быть осторожны даже там: убедитесь, что ссылки на тип не проникают в ваш основной домен приложений, иначе они останутся в памяти.

Есть две ссылки на заре CLR, которые могут оказаться полезными: Выгрузка сборки и Почему нет метода Assembly.Unload? .

Вы смотрели на DLR ? Возможно, что-то вроде ExpandoObject может вам помочь, хотя похоже, что в настоящее время это не поддерживается для привязки данных в Silverlight 4 (может быть в Silverlight 5 ?)

3 голосов
/ 01 октября 2010

.NET 4.0 представляет концепцию коллекционных сборок , подходящих для сбора мусора.Пример использования можно найти здесь .

...