Схема распределения памяти на платформе AnyCPU

Question

Я намеренно теряю память внутри простой программы на C #, чтобы понять, как .NET управляет этим аспектом.Это делается с использованием int[] массивов, каждый размером 10 миллионов, объявляемых каждые 100 мс.Элементы массивов не «прикасаются» - как в назначенном значении - чтобы не вносить данные в рабочий набор процесса:

const int BlockSIZE = 10000000;  // 10 million
const int noOfBlocks = 500;
int[][] intArray = new int[noOfBlocks][];

for (int k = 0; k < noOfBlocks; k++) {
    intArray[k] = new int[BlockSIZE];
    Console.WriteLine("Allocated (but not touched) for array {0}: {1} bytes", k, BlockSIZE);
    System.Threading.Thread.Sleep(100);
}

Я использую VMMap (инструмент, созданныйМарк Руссинович) чтобы посмотреть, как распределяется память.Данная версия является последней (3.25, выпущена в 2018 году), поэтому она знает об управляемой куче.

Visual Studio 2015 используется на компьютере под управлением Windows 10 x64 с 8 ГБ ОЗУ для компиляции и генерации .exe файл.В зависимости от настройки Platform target в разделе «Сборка» проекта можно увидеть различные результаты, связанные с распределением памяти:

Когда для Platform target установлено значение x86, выделенная память увеличивается доблизко к отметке 2 ГБ, прежде чем выдать ошибку нехватки памяти.Это ожидаемое значение, так как 2 ГБ - это предел виртуального адресного пространства пользователя в архитектуре x86 (я не использую IncreaseUserVA, что привело бы к увеличению до 3 ГБ , позже edit : это не совсем правильно - см. ответ Дэвида ниже ).Вывод VMMap в этом случае ниже.Как и ожидалось, большая часть зафиксированных данных попадает в категорию управляемой кучи.

Когда для Platform target установлено значение x64, область фиксациипродолжает расти, как и ожидалось.В конце концов приложение должно быть убито, так как оно продолжает выделять память.Это также ожидалось, поскольку до тех пор, пока общее количество доступных файлов оперативной памяти и подкачки может соответствовать росту, теоретический предел для 64-разрядного блока Win10 составляет 128 ТБ на виртуальное адресное пространство пользователя (как ограничено текущими процессорами).так как они используют только 48 бит из 64 доступных в виртуальном адресе).VMMap вывод ниже.Опять же, большинство принятых байтов подпадают под категорию Управляемая куча.

Когда Platform target имеет значение Any CPU и Prefer 32-bitотмечен - это на самом деле значение по умолчанию в Visual Studio 2015 - результат не так прост. Сначала из всех, исключение нехватки памяти выдается, когда выделенная память достигает примерно 3,5 ГБ. Во-вторых, , частные байты в управляемой куче увеличиваются только примерно до 1,2 ГБ, после чего категория «Частные данные» регистрирует данные, которые распределяются следующим.Вывод VMMap ниже.

Почему распределение происходит, как описано в последнем абзаце для настройки Any CPU + Prefer 32-bit?В частности, почему значительный объем данных указан в разделе «Частные данные» вместо «Управляемая куча»?

Позднее редактирование : для большей наглядности добавлены картинки в строках.

Answer 1

LARGEADDRESSAWARE 32-битные процессы, работающие под Windows в Windows64 (wow64), имеют 4 ГБ виртуального адресного пространства в режиме пользователя (VAS), так как память ядра 64-битная, и ее не нужно отображать в 4 ГБ, адресуемую с помощью 32-битных указателей.И вам не нужно загружать Windows с /3GB switch, чтобы получить его.

При компиляции для X86 вы можете ожидать идентичного поведения на 32-битной и 64-битной платформах, поэтому имеет смысл не устанавливать флаг LARGEADDRESSAWARE.Также это, вероятно, было вызвано обратной совместимостью.В очень старые времена некоторые 32-битные библиотеки (неправильно) использовали старшие биты указателей, поэтому историческое ограничение 32-битных программ до 2 ГБ было безопасным параметром.

AnyCPU + Prefer 32Бит является более новым параметром и по умолчанию устанавливает параметр LARGEADDRESSAWARE, чтобы предоставить вам лучший доступ к ресурсам на 64-битных платформах.