Как я заставляю.NET настойчиво собирать "мусор"?

У меня есть приложение, которое используется в обработке изображений, и я выделяю обычно, выстраивает в 4000x4000 ushort размер, а также случайное плавание и т.п.. В настоящее время платформа.NET имеет тенденцию отказывать в этом приложении, по-видимому, случайным образом, почти всегда с из ошибки памяти. 32 МБ не являются огромным объявлением, но если.NET фрагментирует память, то очень возможно, что такие большие непрерывные выделения не ведут себя как ожидалось.

Существует ли способ сказать сборщику "мусора" быть более агрессивным, или дефрагментировать память (если это - проблема)? Я понимаю, что существуют вызовы GC.Collect и GC.WaitForPendingFinalizers, и я опрыснул их довольно подробно через мой код, но я все еще получаю ошибки. Это может быть, потому что я называю dll стандартные программы, которые используют собственный код много, но я не уверен. Я пробежался через тот код C++ и удостоверяюсь, что любая память, я объявляю, что удаляю, но тем не менее я получаю эти катастрофические отказы C#, таким образом, я вполне уверен, это не там. Интересно, могли ли вызовы C++ вмешиваться в GC, заставляя это оставить позади память, потому что это когда-то взаимодействовало с собственным вызовом - который возможен? Если так, я могу выключить ту функциональность?

Править: Вот некоторый очень определенный код, который вызовет катастрофический отказ. Согласно этому ТАК вопрос, я не должен избавляться от объектов BitmapSource здесь. Вот наивная версия, никакой GC.Collects в ней. Это обычно разрушает на повторении 4 - 10 из процедуры отмены. Этот код заменяет конструктора в пустом проекте WPF, так как я использую WPF. Я делаю дурацкость с bitmapsource из-за ограничений, которые я объяснил в своем ответе на @dthorpe ниже, а также требования, перечисленные в этом ТАК вопрос.

public partial class Window1 : Window {
    public Window1() {
        InitializeComponent();
        //Attempts to create an OOM crash
        //to do so, mimic minute croppings of an 'image' (ushort array), and then undoing the crops
        int theRows = 4000, currRows;
        int theColumns = 4000, currCols;
        int theMaxChange = 30;
        int i;
        List theList = new List();//the list of images in the undo/redo stack
        byte[] displayBuffer = null;//the buffer used as a bitmap source
        BitmapSource theSource = null;
        for (i = 0; i < theMaxChange; i++) {
            currRows = theRows - i;
            currCols = theColumns - i;
            theList.Add(new ushort[(theRows - i) * (theColumns - i)]);
            displayBuffer = new byte[theList[i].Length];
            theSource = BitmapSource.Create(currCols, currRows,
                    96, 96, PixelFormats.Gray8, null, displayBuffer,
                    (currCols * PixelFormats.Gray8.BitsPerPixel + 7) / 8);
            System.Console.WriteLine("Got to change " + i.ToString());
            System.Threading.Thread.Sleep(100);
        }
        //should get here.  If not, then theMaxChange is too large.
        //Now, go back up the undo stack.
        for (i = theMaxChange - 1; i >= 0; i--) {
            displayBuffer = new byte[theList[i].Length];
            theSource = BitmapSource.Create((theColumns - i), (theRows - i),
                    96, 96, PixelFormats.Gray8, null, displayBuffer,
                    ((theColumns - i) * PixelFormats.Gray8.BitsPerPixel + 7) / 8);
            System.Console.WriteLine("Got to undo change " + i.ToString());
            System.Threading.Thread.Sleep(100);
        }
    }
}

Теперь, если я являюсь явным в вызове сборщика "мусора", я должен перенести весь код во внешний цикл для порождения катастрофического отказа OOM. Для меня это имеет тенденцию происходить вокруг x = приблизительно 50:

public partial class Window1 : Window {
    public Window1() {
        InitializeComponent();
        //Attempts to create an OOM crash
        //to do so, mimic minute croppings of an 'image' (ushort array), and then undoing the crops
        for (int x = 0; x < 1000; x++){
            int theRows = 4000, currRows;
            int theColumns = 4000, currCols;
            int theMaxChange = 30;
            int i;
            List theList = new List();//the list of images in the undo/redo stack
            byte[] displayBuffer = null;//the buffer used as a bitmap source
            BitmapSource theSource = null;
            for (i = 0; i < theMaxChange; i++) {
                currRows = theRows - i;
                currCols = theColumns - i;
                theList.Add(new ushort[(theRows - i) * (theColumns - i)]);
                displayBuffer = new byte[theList[i].Length];
                theSource = BitmapSource.Create(currCols, currRows,
                        96, 96, PixelFormats.Gray8, null, displayBuffer,
                        (currCols * PixelFormats.Gray8.BitsPerPixel + 7) / 8);
            }
            //should get here.  If not, then theMaxChange is too large.
            //Now, go back up the undo stack.
            for (i = theMaxChange - 1; i >= 0; i--) {
                displayBuffer = new byte[theList[i].Length];
                theSource = BitmapSource.Create((theColumns - i), (theRows - i),
                        96, 96, PixelFormats.Gray8, null, displayBuffer,
                        ((theColumns - i) * PixelFormats.Gray8.BitsPerPixel + 7) / 8);
                GC.WaitForPendingFinalizers();//force gc to collect, because we're in scenario 2, lots of large random changes
                GC.Collect();
            }
            System.Console.WriteLine("Got to changelist " + x.ToString());
            System.Threading.Thread.Sleep(100);
        }
    }
}

Если я не справляюсь с памятью в любом сценарии, если существует что-то, что я должен определить с профилировщиком, сообщить мне. Это - довольно простая стандартная программа там.

К сожалению, похоже, что ответ @Kevin является правильным - это - ошибка в.NET и как.NET обрабатывает объекты, больше, чем 85k. Эта ситуация кажется мне чрезвычайно странный; Powerpoint мог быть переписан в.NET с этим видом ограничения или каким-либо из других приложений Пакета офисных программ? 85k, кажется, мне не много пространства, и я также думал бы, что любая программа, которая использует так называемые 'большие' выделения часто, становилась бы нестабильной в течение нескольких дней к неделям при использовании.NET.

Править: Похоже, что Kevin прав, это - ограничение GC.NET. Для тех, кто не хочет следовать за всем потоком.NET имеет четыре "кучи" GC: gen0, gen1, gen2, и LOH ("Куча" для больших объектов). Все это - 85k или меньший, идет на одну из первых трех "кучи", в зависимости от времени создания (перемещенный от gen0 до gen1 к gen2, и т.д.). Объекты, больше, чем 85k, помещаются в LOH. LOH никогда не уплотняется, поэтому в конечном счете, выделения типа, который я делаю, в конечном счете вызовут ошибку OOM, поскольку объекты рассеиваются о том пространстве памяти. Мы нашли, что перемещение в.NET 4.0 действительно помогает проблеме несколько, задерживая исключение, но не предотвращая его. Честно говоря, это чувствует немного как 640k барьер - 85k, должен быть достаточно для любого пользовательского приложения (для перефразирования этого видео обсуждения GC в.NET). Для записи Java не показывает это поведение со своим GC.