Тема “вопрос про память в dot.net”

Дано - Win2k, 1гб оперативной памяти.

Пишется c# программа, подцепляющяя две проприетарные COM библиотеки (через reference) для работы с некоторыми специальными объектами (молекулы в данном случае).

через функции этих ком библиотек молекулы грузятся в память. Для некоторой вычислительно емкой задачи возникает вариант - чтобы не мучаться с импортом экспортом молекул, по возможности максимально загрузить их в память и работать с ними оттуда. Эмпирический эксперимент показывает, что если начать бесконтрольно грузить память молекулами, на ~300 Мегабайтах (смотрел в TaskManager) занимаемой памяти программа вылетает с ошибкой:

Attempted to read or write protected memory.This is often an indication that other memory is corrupt.

Вопросы

1) Правильно ли я понимаю, что это я забиваю всю свободную динамическую память (рабочее множество, Working set), которую может под .net программу выделить операционная система? То есть 300 мб - примерный объем памяти, вообще доступный .net среде? Или ошибка памяти происходит из за того, что COM объекты до конца выгребают какую-то свою, отдельную память?

2) Как можно узнать объем памяти, занимаемый конкретным объектом? Можно ли оптимизиовать этот объем? Например, подобно функции TrimExcess для дженериков (list-ов и т.п).

3) Есть ли какие-нибудь полезные инструменты для работы с .net памятью?

Насколько мне известно, специальных ограничений памяти для дотнет нет. То есть, твой процесс может свободно работать с объемами памяти гораздо большими, чем 300 мегабайт.

Сама ошибка говорит о том, что кто-то полез в область памяти, для него не предназначенную. Анменеджед код, конечно.

Иными словами, где-то есть баг в этих самых COM-библиотеках, видимо, либо просто не отслеживают память, что, впрочем, тоже баг.

А ошибку тебе вываливает сама винда, которая за работой с памятью строго следит и пресекает попытки лезть не туда, куда надо.

По поводу оптимизации памяти и т.д. - нет, для managed-объектов это up to CLR где и как размещать объекты, когда их убивать, когда дефрагментировать кучи и т.д. Ты этим управлять не можешь никак.

Для unmanaged-кода действуют "обычные" правила.

Инструмент для _работы_ с .net-памятью только один, GC, и его лучше не пинать

Есть всяческие профайлеры памяти для дотнета, которые могут показать тебе что, где и сколько занимает, в каком поколении GC находится и т.д.

Поищи в гугле по .NET Memory Profiler.

Вполне допускаю что просто баг в самой библиотеке - при большом количестве объектов ошибки в адресной математике ну и в результате - лезет куда не надо. Если попробовать другой набор данных подгрузить?

Пробовал на разных данных - та же шняга - ~300 МБ и привет. За квалифицированную консультацию спасибо. Действительно похоже на внутренние проблемы сторонних библиотек.