Несколько странной показалась мне работа с памятью..

Программа до смешного простая: в цикле аллоцирует память по элементам массива длины m. Каждый элемент - упакованный в структуру массив длины L. Цель программы - продемонстрировать ученику работу с динамической памятью.. В качестве самого первого приближения использую конструкцию с malloc(). Код, как результат импровизации, вышел неким гибридом C и C++ (так сказать, C+-)) Для наглядности я открыл TaskManager на закладке Performance. При m=2000 и L=10⁶ я ожидал, что используемая память вырастет на 2 ГБ. Вставил задержку в цикл аллокации памяти, чтоб был наклон графика памяти. Думаю - сейчас мой ученик все увидит своими глазами. Запускаю прогу..

Ага, разбежался! Кривая графика памяти даже не шелохнулась..

Ход мысли такой: БЛИН!!!!!!!!!!!!!!!!! ГДЕ-ТО ОШИИИИИИБКА!! КЭШМЭРР!!

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

Дальнейший ход мысли: НАДО ДЕБАГГИТЬ..

При отладке замечаю, что вся аллоцированная память инициализирована нулями.. Что ж, если так, то она может быть и упакована. Вставляю в цикл инициализацию всего массива, и..

О, СЧАСТЬЕ!! наконец-то моя программа начинает ЖРАТЬ ПАМЯТЬ! Сжирает ровно столько, сколько положено (а чудес я и не ждал)). Если же я делаю заполнение половины массива, то получаю половинный расход памяти.

Первый пик - инициализавция всего массива (почти, то есть через один элемент), второй - только первой половины, третий - только второй половины.

Вопрос, я полагаю, вы уже поняли. Кто занимается этим грязным бизнесом - компилятор или система? И вообще - какого, извините, черта?

Компилятор - gcc (MinGW + C::B). Debug и Release ведут себя одинаково (в среде и без).
OS - Windows 7 Pro 64

Вопросом на вопрос (мне можно ) : А кто тебе сказал, что TaskManager показывает тебе аллоцированную malloc-ом память именно в Physical Memory? Виртуальную память проверял? malloc() увеличивает WorkingSet, то есть работает именно с виртуальной памятью (фактически, если мне память не изменяет, под Win функция malloc() = VirtualAlloc() + MEM_COMMIT). А уж потом, когда эта память начинает использоваться - тут уже начинает возрастать потребление памяти физической.

А вообще, на RSDN была такая развлекуха: Развлечение - построить график заданной функции

Сообщение отредактировано: IUnknown - 5.08.2011 13:46

Я, конечно, думал про своп , но одна неувязка сбивала с толку эту мыслю.. А именно, что память обнулена. Не есть ли сие странно?..

У меня тоже это мелькнуло в процессе

Андрей, ну будь внимательнее: и MSDN -> VirtualAlloc Function, которая гласит:
Что ж тут странного? Что функция WinAPI отрабатывает ровно так, как заявлено? Ну, может, ты и прав, странно это

Вот под *nix-ами - тут да, не обнуляется память при malloc(), только calloc()-ом...

Вот теперь все встало на свои места )), спасибо!
+1

[offtop, хоть и не совсем]
Покрутивши это все в мозгах, я пришел к интересному (по крайней мере, для меня) выводу. Получается, что во время вызова malloc(), реального выделения памяти совершенно и не происходит. А происходит как бы то, что OS дает обещание выделить ее "по первому требованию". Точно так же, как банк (реальный, денежный) раздает займы клиентам - он не выдает наличные в тот же самый момент. И реально получается, что он тратит больше, чем имеет.

Подсистема памяти в ответ на запрос на кусок К мегабайт возвращает адрес начала (вексель). Приложение может сразу начать использовать память, а может отложить это на какое-то время. Вот когда происходит реальное обращение по адресу внутри этого куска - тогда он реально отводится и инициализируется (обналичивается). То есть, что я хочу сказать, это то, что до того момента этот кусок реально не присутствует нигде. В самом деле - было бы слишком хлопотно расписывать нулями громадную область памяти на диске (в свопе), а потом считывать этот кусок в память.. Зачем?? достаточно хранить границы и.. - хотел сказать, 0, но потом подумал, что это тоже лишнее, поскольку инициализации другим числом просто не бывает .

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

.. но аналогия просматривается и еще дальше.. Если этот банк не частный, а государственный - то бабок можно напечатать, сколько угодно! И что тогда? И вот тогда происходит та самая пресловутая инфляция, и экономика государства резко тормозится.. А что с компьютером? Он тоже резко тормозится, если реальная память слишком мала и мы пытаемяся заставить его работать на виртуальной..

Вот такая аналогия )).
[/offtop]