Адресное пространство под микроскопом

Продолжаем тему про память в программах Delphi.

В прошлый раз мы узнали о том, что понятие "память" в программах представляет собой большой однородный массив байтов, где и хранится в куче вообще всё, с чем напрямую работает программа. Массив этот виртуален, не ограничен количеством физической памяти, индивидуален у каждой программы и достаточно велик, чтобы вы не задумывались о его ограничениях 99% времени. Большой размер, изолированность и однородность существенно упрощает разработку программ.

Ну, вообще-то я вам наврал. Извините, если вы мне поверили.

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

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

Достаточно пёстрая картина, не так-ли?

Основные регионы

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

• Виртуальная память
  1. Виртуальное адресное пространство
     1. Режим пользователя
        1. Область для отлова нулевых указателей
        2. Зарезервированный блок в 64 Кб на границе 2 Гб
        3. Раздел для кода и данных программы
           1. Код
           2. Данные
              1. Проецируемые в память файлы
                 1. Частные
                    1. Именованные
                    2. Безымянные
                 2. Разделяемые
                    1. Именованные
                    2. Безымянные
              2. Основная рабочая виртуальная память
                 1. Частная память
                    1. Стек
                    2. Куча
                    3. Прочая (динамическая память)
                 2. Разделяемая память
           3. Недоступная память
              1. Потерянная память
              2. Свободная память
     2. Режим ядра
  2. Виртуальная память, не имеющая прямого отображения в адресном пространстве

Сразу предупрежу, что эта схема - просто один из способов классификации различных зон внутри виртуального адресного пространства. Она не является ни точной (к примеру, не показана/не раскрыта область режима ядра), ни абсолютной (вы можете сгруппировать классификацию и по-другому - к примеру, поделить проецируемые файлы сначала по доступности, а потом по именованности; или вообще вынести "разделяемость" на уровень выше, захватив заодно и секции кода). Также на этой схеме вообще никак не отображено отношение между физической и виртуальной памятью. Тем не менее, эта схема может пригодиться как отправная точка.

Секции кода, секции данных

Пожалуй, первое, что бросается в глаза - мы видим в "памяти программы" саму программу! (А также все библиотеки, которые она использует). Эта зона в VMMap называется Image и она помечена фиолетовым цветом. Несложно сообразить, почему это так. "Память программы", хотя теперь и виртуальна, является эмуляцией физической памяти (RAM, оперативной памяти). Процессор не может выполнять машинный код на внешней памяти (дисках, флешках) - он может обрабатывать только код в оперативной памяти. Поскольку виртуальная память является эмуляцией физической, то отсюда напрямую следует, что программа должна быть загружена в виртуальное адресное пространство, чтобы её можно было выполнить.

Программа появляется в адресном пространстве с помощью механизма проецирования файлов. Exe-файл проецируется на адресное пространство программы и становится его частью. Любое обращение к памяти по этим адресам приведёт к фактическому чтению данных с диска. С точки зрения программы эта часть выглядит как обычная "память", ничем не отличающаяся от любой другой памяти. Но на самом деле эта память читается из файла на диске.

Тут надо сделать замечание, что "обычная" виртуальная память так же может читать из файла при обращении к ней. К примеру, как мы помним, при недостатке физической памяти, часть виртуальной памяти может быть выгружена из физической памяти на диск - в файл подкачки (т.н. страничный файл, paged file).

Вот пример загруженного Total Commander:

Как вы можете видеть, весь 3.5 Мб .exe файл при загрузке в память оказался поделенным на части. Причём у всех частей оказался разный способ доступа. Это связано с тем, что в .exe файле хранятся разные вещи: код, константы, ресурсы, данные. Соответственно, они и обрабатываются по-разному. Я уже упоминал о том, что на уровне ВУ языка данные характеризуются именем-типом-семантикой, а на уровне процессора - адресом, размером и атрибутами доступа. Вот сейчас мы видим, что собственно исполняемый код Total Commander оказался размером в 2.8 Мб и имеет атрибуты доступа "чтение и выполнение" (на рисунке он выделен). Непосредственно перед ним идёт PE-заголовок .exe файла, имеющий доступ только для чтения. Заголовок программы содержит информацию о ней - сколько в ней кода, сколько данных, какие требования для её выполнения (вроде версии ОС, атрибутов запуска вроде флагов LargeAddressAware и т.п.). Всё, что идёт после секции кода является различными данными. Соответственно, у секций данных доступ либо только на чтение, либо на чтение/запись. Их мы рассмотрим чуть позже. Исключением (с атрибутом копирования при записи) является секция .idata, которая имеет специальное назначение - это вспомогательный блок для оптимизации статического импорта функций из библиотек. Но это не тема этой статьи.

Атрибуты защиты (доступа) выставляются на уровне страниц памяти (размер страницы памяти - 4 Кб). Соблюдение режима доступа контролируется аппаратно, самим процессором. Если вы попробуете выполнить недопустимую операцию (вроде записи по адресу, принадлежащему странице с атрибутом доступа "чтение"), то процессор возбудит исключение нарушения доступа (Access Violation). Кстати, это (доступ к странице памяти с неверным доступом) - единственная причина для возникновения этого исключения.

Атрибуты защиты в чём-то похожи на аппаратное разделение на режим ядра и режим пользователя - в том смысле, что они предоставляют защиту от ошибок (непреднамеренного/ошибочного доступа "не туда"). И защита эта выполняется на аппаратном уровне. Хотя, конечно, в отличие от разделения на режимы ядра и пользователя, вы можете менять атрибуты защиты страницы.

Всего есть три атрибута - чтение, запись и выполнение, которые могут комбинироваться в любой последовательности (отсутствие атрибутов можно считать как атрибут "no access" - PAGE_NOACCESS), а также два специальных модификатора - copy-on-write и guard (будут рассмотрены ниже). Секции данных обычно имеют доступ на чтение (константы), чтение/запись (переменные), а секции кода - на чтение и выполнение. Иногда вы можете генерировать код на лету. В этом случае вы должны добавлять атрибут "выполнения" (и, предпочтительно, снять атрибут "записи") к памяти, в которой хранится сгенерированный код, перед его выполнением. Иначе вы схлопочете свой законный вылет - нельзя запустить код, который не имеет атрибута "выполнение" (а только "чтение").

Примечание: на ранних процессорах архитектуры x86 атрибуты "чтение" и "выполнение" были эквивалентными. Поэтому, хотя технически ставить равенство между ними никогда не было верным, некоторые воспользовались этой особенностью реализации и передавали управление на код в сегментах данных. Повторим: это никогда не было корректным, но это работало на старых процессорах. Теперь этот код будет вылетать. См. также: DEP.

Проецируемые файлы

Помимо самой программы и её библиотек в адресном пространстве программы проецируемые файлы могут присутствовать и как рабочие объекты. Их может создавать и использовать код программы. В VMMap эти регионы называются Mapped Files и маркированы синим цветом.

Проецирование файлов - это удобный способ обработки данных. Вы делаете вид, что данные как-бы находятся в памяти, хотя, на самом деле, они расположены на диске. Вам не нужно писать явный код загрузки файла в память, вы экономите на перемещении блоков памяти. Всё это за вас делает ОС автоматически, с вашей же точки зрения это обычная память.

Операции с файлами — это то, что рано или поздно приходится делать практически во всех программах, и всегда это вызывает массу проблем. Должно ли приложение просто открыть файл, считать и закрыть его, или открыть, считать фрагмент в буфер и перезаписать его в другую часть файла? В Windows многие из этих проблем решаются очень изящно — с помощью проецируемых в память файлов (memory-mapped files).

Как и виртуальная память, проецируемые файлы позволяют резервировать регион адресного пространства и передавать ему физическую память. Различие между этими механизмами состоит в том, что в последнем случае физическая память не выделяется из страничного файла, а берется из файла, уже находящегося на диске. Как только файл спроецирован в память, к нему можно обращаться так, будто он целиком в нее загружен.

Кроме этого, проецируемый в память файл может иметь имя и быть разделяемым, т.е. совместно использоваться двумя и более программами. Это удобный механизм обмена данными между двумя процессами (IPC) на базе которого построены почти все прочие механизмы межпроцессного обмена данными. Вспомните, что виртуальное адресное пространство у каждой программы своё, оно изолировано. Иными словами:

procedure TForm1.Button1Click(Sender: TObject);
var
  I: PInteger;
begin
  I := какой-то-адрес-в-другой-программе;
  Tag := I^; // I будет трактоваться относительно ВАШЕГО адресного пространства
end;

Этот код будет делать всяческие плохие вещи (вылет с Access Violation, вылет программы, чтение мусора), а не то, что вы ожидаете (чтение данных из другой программы), потому что вы не приняли во внимание изолированность программ. В вашей программе по этому адресу лежит что-то совершенно иное. Это примерно как на каждой улице (программе) есть дом номер 3 (адрес памяти). Вы не можете сказать "дом 3" и надеяться, что письмо дойдёт. Более того, даже хотя вы можете как-бы "приписать" к "дом 3" "название улицы" (ID процесса) - с помощью функций вроде ReadProcessMemory и WriteProcessMemory - это не является рекомендуемым способом обмена данными. А вот разделяемые проецируемые в память файлы (и любые другие механизмы IPC, которые, так или иначе, на них основаны) как раз и являются тем, что вам нужно использовать, если вы хотите организовать взаимодействие между двумя программами.

Частная и разделяемая память

Итак, за вычетом проецируемых файлов (которые делятся на собственно проецируемые файлы и загруженные исполняемые модули), у нас остаётся "основная масса памяти". Большую часть из неё занимают обычные данные, которые индивидуальны для нашей программы. Это т.н. private (частные) данные. В VMMap они выделены жёлтым цветом (надо иметь в виду, что VMMap также выделяет часть private-данных в отдельные области - см. ниже). Эти данные используются только нашей программой и не имеют отображения в других программах. Т.е. это самая типичная память программы. Кроме частных данных в адресном пространстве есть и т.н. shareable (разделяемые) данные. Это специальным образом оформленные секции DLL-файлов, которые совместно используются несколькими программами. Delphi не поддерживает создание подобных секций, так что мы не будем подробно рассматривать их. Следует также заметить, что некоторые проецируемые в память файлы также могут совместно использоваться несколькими программами. Кроме того, совместно используются и любые секции кода (за исключением ситуаций, когда их модифицируют при выполнении): если запущено 10 экземпляров программы, то нет смысла держать в памяти 10 копий .exe файла. Поэтому, хотя в системе будет 10 различных виртуальных адресных пространств, и во всех них будет 10 .exe файлов, на самом деле, все эти .exe файлы будут одним и тем же файлом, спроецированным на вcе адресные пространства. Т.е. вместо 10 копий в оперативной памяти будет всего одна.

Потерянная и свободная память

Это все основные регионы, которые можно использовать. Вся прочая память является недоступной. Любое обращение к ней приводит к возбуждению исключения нарушения доступа (Access Violation) - это частный случай неправильного доступа памяти (к примеру, попытка чтения данных со страницы памяти с атрибутом доступа PAGE_NOACCESS). Но даже недоступная память делится на две категории. Ну, самое очевидное - свободная память. Это память, которая ещё не занята. Такой у нас большинство. В VMMap это белые блоки (free memory). Кроме свободной памяти в недоступной памяти числится память, которая не может быть использована из-за фрагментации (серый цвет в VMMap, unusable). Вспомним, что память выделяется кусками по 64 Кб, но гранулярность блока памяти - размер страницы (что есть 4 Кб). Это означает, что если вы выделите 2 Кб, то вам выделят 4 Кб, а 60 Кб окажутся навеки недоступными - ну, пока вы не освободите эти ваши 2 Кб (на самом деле - 4 Кб) памяти, так что весь блок в 64 Кб не станет вновь целиком доступен для использования.

Классификация основной рабочей памяти

Фух, выше было сказано ужасно много всего. Но, кажется, это было довольно далеко от простого var I: Integer, не так ли? Да, довольно далеко. Но это было необходимо, чтобы протянуть мостик между адресным пространством (системным понятием) и var I: Integer (понятием ВУ языка). Теперь, когда мы немного их сблизили, настало время поговорить "поближе к Delphi". Начнём, пожалуй, с самого простого, что только может быть в вашей программе:

Константы

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

Один из способов - это устаревшее использование констант. Т.н. режим "writable const" (опция {$J+}/{$J-}). Это режим, при котором константа фактически трактуется как переменная. В современной Delphi не имеет смысла, кроме обратной совместимости с (очень) старым кодом.

Если исключить из рассмотрения эти "константы-переменные", то у нас остаётся два способа, показанные в этом (бессмысленном) куске кода:

procedure TForm1.Button1Click(Sender: TObject);
const
  I = 3;
  A: array[0..3] of Char = 'asd';
begin
  Tag := I;     // Встраивание константы в код
  Caption := A; // Размещение константы в секции глобальных данных
end;

Простейшие константы встраиваются непосредственно в генерируемый машинный код (кстати, это одна из причин, почему секция кода имеет атрибут доступа "чтение" помимо атрибута "выполнение"). В нашем примере это константа I.

Более сложные константы, которые имеют большой размер, обрабатываются иначе. Все они записываются в один большой блок - сегмент данных, который записывается в .exe файл после секции кода. Генерируемый машинный код (помещаемый, конечно же, в секцию кода) обращается (указывает) на данные в секции данных - туда, куда компилятор поместил константу.

Таким образом, константы появляются в памяти автоматически, вам ничего и никогда не нужно для этого делать - если программа загрузилась в память, то вместе с ней загружены и константы. Но это не значит, что об управлении памятью вам придётся навсегда забыть. К примеру, если вы загрузили DLL, вызвали функцию в ней, она вернула вам указатель на данные-константу (к примеру, её GUID), а затем вы выгрузили DLL и пытаетесь обратиться к данным по указателю - то вы, конечно же, получите свой законный Access Violation, потому что страницы памяти, которые некогда занимала константа, после выгрузки DLL оказываются свободными (имеют атрибут PAGE_NOACCESS).

Кстати, как паковать константы вместе и как их хранить - сугубо деталь реализации компилятора. Далеко не факт, что данные константы будут иметь атрибут защиты "только чтение". Да, "только чтение" - это то, что мы могли бы ожидать, и что нам хотелось бы. Но на практике компилятор может помещать константы в один блок с другими данными (которые имеют доступ чтение/запись), так что разграничить их не представляется возможным. Впрочем, мне пока не встречалось ни одной ситуации, где бы это имело значение.

Глобальные переменные

Глобальные переменные, хотя и могут не только читаться, но и писаться (в сравнении с константами), на деле являются ещё более простыми вещами, поскольку трактуются всего одним образом. И способ этот очень похож на хранение сложных констант. Все глобальные переменные складируются в одну кучу, в один блок памяти. Но в отличие от констант, глобальные переменные (обычно) не сохраняются в .exe файле. Вместо этого в .exe файле создаётся специальная секция "инициализация нулями при загрузке". Указывается только размер. При загрузке .exe файла в память ОС выделит пустой блок памяти, заполненный нулевыми байтами нужного размера - это и будет область для наших глобальных переменных (кстати, на рисунке с Total Commander-ом выше эта область называется BSS). Таким образом, все глобальные переменные инициализируются нулями - это механизм не языка, а ОС (причём аналогичный механизм существует во многих других системах).

Но что же насчёт инициализированных глобальных переменных, спросите вы? Ну, тут может быть несколько подходов, но самый типичный - выделение инициализированных глобальных переменных в отдельный блок памяти. Все инициализированные переменные сохраняются в сегмент данных. Он помещается в .exe файл (обычно - в сегмент с именем DATA). При загрузке программы этот сегмент загружается в память и получает доступ на чтение/запись. Некоторые компиляторы складируют в этот блок (DATA) как инициализированные глобальные переменные, так и константы.

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

Собственно, замечания по управлению памятью те же, что и для констант: глобальные переменные доступны всегда, до тех пор, пока в память загружен "их" исполняемый модуль. Вам ничего не нужно делать для управления ими.

Ресурсы

Если вы внимательно дочитали до этого момента, то вы уже догадываетесь, что я хочу здесь сказать: да, ресурсы в .exe файле работают практически как константы: они собраны в единую секцию (.rsrc), которая доступна в памяти одновременно с наличием там самого исполняемого файла. Вы можете получать к ним доступ как к любым другим данным. Конечно же, по-хорошему, вам нужно использовать кучу функций для этого - вроде LoadResource и LockResource, но надо понимать, что эти функции - наследие старых времён, когда загрузка файла в память (да и работа с памятью вообще) выполнялась существенно иначе. В современном мире плоской модели памяти эти функции существуют только для обратной совместимости.

Во избежание недоразумений: я не говорю вам обращаться к ресурсам напрямую, минуя функции доступа. Не делайте этого.

Динамическая память

Хотя мне очень хочется перейти уже наконец-то к нашему простому var I: Integer, мне кажется, что будет лучше дать сперва более простой материал: динамическую память и кучу.

Динамическая память - это память, получающаяся из свободной памяти при выделении памяти. Слово "динамическая" здесь означает "динамически распределяемая". Т.е. в отличие от статической памяти (которая постоянна на длительных участках выполнения программы), динамическая память характеризуется своим непостоянством - она выделяется и освобождается во время выполнения кода программы. Статическая же память выделяется при загрузке программы (модуля) и освобождается при её выгрузке. Динамическая память используется когда вы не знаете размер данных и/или их количество на этапе кодирования. К примеру: какого размера будет файл, сколько в нём будет строк и т.п. В этом случае вы не выделяете никаких ресурсов в программе изначально, но вместо этого вы выделяете память по необходимости уже во время выполнения программы.

Динамическая память выделяется и освобождается функциями VirtualAllocEx и VirtualFreeEx (а также любыми их аналогами или обёртками вроде VirtualAlloc/VirtualFree).

Собственно здесь всё достаточно просто и прямолинейно: вы вызываете VirtualAlloc(Ex), указывая размер блока памяти и желаемый атрибут доступа (обычно: чтение-запись). Система откусывает от свободной памяти блок, округлённый до "нужных кратностей" и отдаёт его вам. Теперь у вас в программе выделена память, а на руках у вас есть указатель - делайте с ним что угодно. Когда память надо освободить - вызывайте VirtualFree. Система переведёт память обратно в свободную. Достаточно прозрачно.

Конечно, тут есть ещё много возможностей вроде резервирования без выделения памяти, смены защиты во время выполнения, но об этом как-нибудь в другой раз.

Куча

Как я уже не раз указывал: выделение памяти напрямую через системные функции - не самая удачная идея. Поэтому обычно в программе для управления памятью используют другой механизм: кучу (heap).

Иногда термин "куча" употребляют как синоним термина "динамическая память". Это имеет смысл с точки зрения строгой терминологии: ведь куча (по определению) - это название структуры данных, с помощью которой реализована динамически распределяемая память приложения.

С другой стороны, термин "куча" употребляется и в другом смысле - когда ссылаются на вполне конкретный механизм (например: системную кучу процесса или любой другой менеджер памяти). Поэтому вам нужно выделять контекст разговора и каждый раз понимать, что конкретно понимается под "кучей".

Для удобства, здесь и далее я буду полагать такую интерпретацию: любая куча является динамической памятью. Но не любая динамическая память - куча. Память, выделяемую через VirtualAlloc(Ex), будем называть "динамической памятью", но не "кучей". А под "кучей" будем понимать дополнительный код по управлению памяти, реализованный "поверх" динамической памяти: т.н. менеджер памяти или диспетчер кучи.

Такая интерпретация имеет смысл: ведь смысл кучи сводится к обработке множества запросов на создание/разрушение множества мелких объектов (блоков памяти). Очевидно, что "голая" динамическая память (через VirtualAlloc(Ex)) крайне плохо приспособлена к этой задаче (из-за ограничений на кратность выделения и размера). А вот различные менеджеры памяти как раз и созданы для решения этой задачи. Так что к ним как нельзя лучше подходит термин "куча".

Именно куча (через менеджер памяти Delphi) является стандартом для работы с динамической памятью в Delphi. Все запросы на создание объектов, выделения памяти идут через стандартный менеджер памяти Delphi. Крайне редко при этом используются иные механизмы.

Менеджер памяти в Delphi представлен функциями GetMem, FreeMem и ReallocMem. Все прочие функции (New/Dispose, AllocMem, SetLength, TObject.Create и т.п.) являются лишь обёртками к этим низкоуровневым функциям менеджера памяти Delphi. Эти обёртки удобнее использовать, чем функции менеджера памяти, потому что они выполняют некоторую вспомогательную работу (самая типичная - вычисление размера в байтах по типу переменной и количеству элементов). Использование GetMem и FreeMem очень похоже на использование VirtualAlloc и VirtualFree - разница только в меньшем объёме функций (к примеру, память всегда выделяется только на чтение/запись), да в том, что память берётся не напрямую из системы, а из предварительно выделенной памяти.

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

Как уже было сказано, куча весьма удобна при создании множества мелких блоков данных. Например, связанными списками и деревьями проще манипулировать, используя именно кучу, а не динамическую память. Преимущество кучи в том, что она позволяет вам игнорировать гранулярность выделения памяти и размер страниц и сосредоточиться непосредственно на своей задаче - т.е. абстрагироваться от особенностей железа (аппаратной части). А недостаток является прямым следствием преимущества: вы теряете прямой контроль над передачей физической памяти и её возвратом системе. Что касается скорости работы, то она сильно зависит от специфики данных. Как правило, менеджер памяти оптимизируется под типичные операции в программе и работа с ним наиболее оптимальна в большинстве случаев. С другой стороны, могут быть вырожденные случаи, когда накладные расходы на управление памяти в куче перевешивают выигрыш от экономии на вызовах ядра (вызов VirtualAlloc(Ex) означает обращение к режиму ядра, а переключение контекстов (пользовательский режим -> режим ядра и обратно) - не самая быстрая операция).

Далее надо сказать, что стандартный менеджер памяти Delphi - это не единственный диспетчер кучи в вашей программе. Вам также доступны (как минимум) эти варианты:

• HeapAlloc/HeapFree
• LocalAlloc/LocalFree
• GlobalAlloc/GlobalFree
• IMalloc.Alloc/IMalloc.Free
• CoTaskMemAlloc/CoTaskMemFree
• SHAlloc/SHFree

Чем они отличаются? Да мало чем. Это разные реализации одной идеи. В системе есть несколько менеджеров памяти, которые имеют разные цели и используются в разных случаях. Вышеуказанные функции - это точки доступа к различным менеджерам памяти (которые, кстати, не имеют никакого отношения к Delphi). Когда их надо использовать? Когда вам нужно "поговорить" с другим кодом, который понимает только их. К примеру, буфер обмена Windows работает с GlobalAlloc/GlobalFree. А в остальных случаях (т.е. почти всегда) вам нужно использовать менеджер памяти Delphi.

Самое главное, что тут нужно знать - это правило: "кто память выделил - тот её и должен освобождать". Иными словами, если вы выделили память через GetMem - то и освобождать её должны через FreeMem. Если память выделена через VirtualAlloc, то освобождать её надо через VirtualFree. Если выделена через LocalAlloc - то LocalFree. И так далее. Нельзя смешивать одно с другим.

Да, кстати, VMMap показывает и кучу и динамическую память одинаково - как "Private Data" (жёлтым цветом). А вот системную кучу процесса (HeapAlloc/HeapFree) она показывает отдельно - как "Heap (Private Data)" (красный цвет).

См. также:

• В чём разница между LocalAlloc и GlobalAlloc?
• В чём разница между SHGetMalloc, SHAlloc, CoGetMalloc и CoTaskMemAlloc?
• Менеджеры памяти в программах

Стек

Ну, наконец-то мы добрались до самого конца: нашего долгожданного var I: Integer. Локально объявленные переменные простых (не динамических) типов называются "статическими". Следующий (бессмысленный) пример кода демонстрирует объявление всех выше обсуждаемых :

program Test;

// Глобальные константы - статические данные
const
  {$J+}
  C1: Integer = 1;          // замаскированная глобальная переменная
  {$J-}
  C2 = 5;                   // "встраиваемая" константа
  C3: array[0..1] = (5, 1); // "ссылаемая" константа

// Глобальные переменные - статические данные
var
  GV1: Integer;                // "zero-init"  переменная (простой тип)
  GV2: array[0..1] of Integer; // "zero-init"  переменная (статический массив)
  GV3: Integer = 1;            // переменная с инициализацией

// Глобальные переменные - динамические данные
  GV4: Pointer;                // указатель
  GV5: TObject;                // объект
  GV6: array of Integer;       // динамический массив

// Ресурсы
resourcestring
  RS1 = 'There is no cow level'; // Строка в таблице строк

{$R *.res}                       // Прочие ресурсы 

  procedure P;
  // Локальные переменные - статические данные
  var
    LV1: Integer;                // не инициализируемая переменная (простой тип)
    LV2: array[0..1] of Integer; // не инициализируемая переменная (статический массив)
    LV3: Integer = 1;            // <- не скомпилируется

  // Локальные переменные - динамические данные
    LV4: Pointer;                // указатель
    LV5: TObject;                // объект
    LV6: array of Integer;       // динамический массив
  begin
  end;

begin
end.

Для начала заметим такую простую вещь: хотя в данном примере GV4-6 и LV4-6 - динамические и выделяют память под свои данные в куче, но сами переменные (все из которых являются 4-х байтовыми указателями на x86-32 и 8-ми байтовыми указателями на x86-64) являются статическими. Иными словами, у чисто статических переменных "переменная" = "данные". У динамических переменных "переменная" <> "данные" - у них "переменная" = "указатель", а "данные" находятся по этому указателю. Кроме того, хотя в этом примере все 6 динамических переменных оказались "статическими" (как собственно переменные, а не данные) - но в общем случае это может быть не так: к примеру, переменная может быть и полем объекта - и, следовательно, выделяться в куче. Например:

type
  TTest = record
    Next: Pointer;
  end;
  PTest = ^TTest;

Здесь Next может располагаться как статически (если вы просто объявите глобальную переменную типа TTest), так и динамически - если вы выделите память под TTest через GetMem/AllocMem/New (получив на руки указатель PTest).

Но это было лирическое отступление. Итак, если вы внимательно посмотрите на код выше, то заметите две странных вещи:

1. Локальные переменные не инициализируются нулями
2. Локальным переменным нельзя задать значение при объявлении

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

В коде отсутствуют операции выделения/освобождения памяти (вроде GetMem/FreeMem), но локальные переменные автоматически доступны - значит, можно предположить, что они не размещаются ни в куче, ни в динамической памяти. А где тогда?

В адресном пространстве любого процесса есть как минимум один очень специальный регион памяти, называемый "стеком потока". Всякий раз, когда в процессе создается поток, система резервирует регион адресного пространства для стека потока (у каждого потока свой стек) и передает этому региону какой-то объем физической памяти. По умолчанию система резервирует 1 Мб адресного пространства и передает ему всего две страницы памяти (размер резервируемого региона по умолчанию указывается в заголовке PE файла; он так же может явно указываться вызывающим при создании потока).

Именно в стеке потока и хранятся локальные переменные.

Но это ничего не объясняет. Почему "стек"? И разве он не в динамической памяти выделяется?

Давайте по порядку.

Итак, почему - "стек"?

"Стек" (англ. "stack" — стопка) — это структура данных, в которой доступ к элементам организован по принципу LIFO (англ. last in — first out, "последним пришёл — первым вышел"). Чаще всего принцип работы стека сравнивают со стопкой тарелок: чтобы взять вторую сверху, нужно снять верхнюю:

Операция помещения элемента в стек называется "заталкиванием" (push), а обратная к ней - "выталкиванием" (pop). Обе операции возможны только по отношению к верхушке стека.

Хорошо, а какое это имеет отношение к локальным переменным?

Вспомните, что локальные переменные - "свои" у каждой функции и процедуры:

procedure Test1;
var
  I: Integer;
begin
end;

procedure Test2;
var
  I: Integer; // этот I - не тот же самый I, что в Test1
begin
  Test1;
  I := 1; // работаем с Test2.I, а не с Test1.I
end;

Более того: эти переменные - "свои" у каждого вызова одной и той же функции:

// Здесь N - это тоже локальная переменная
function Fact(const N: Integer): Integer;
begin
  if N = 0 then
    Result := 1
  else
    // Здесь: N текущего вызова - не то же самое,
    // что N внутри -второго- вызова Fact 
    // (где она будет меньше на 1)
    Result := N * Fact(N - 1);
end;

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

Каждый раз, когда вы вызываете функцию или процедуру, её данные размещаются на вершине стека, указатель текущего места сдвигается, чтобы указывать на новую вершину. Когда же функция или процедура завершает выполнение и возвращает управление, её данные удаляются из стека, а вершина стека "сползает" к предыдущей процедуре.

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

Кстати, стек растёт "в обратную сторону": от старших (бОльших) адресов в сторону младших (меньших). В частности, на рисунке выше 0 (nil), будь он показан, располагался бы где-то сверху. А граница в 4 Гб (16 Эб для x86-64) - где-то снизу.

Хорошо, со "стеком" более-менее понятно - но почему тогда "статические"? Вроде описанный механизм сильно напоминает динамический? Ведь память выделяется и освобождается в процессе работы программы.

Действительно, статические локальные переменные - это не то же самое, что статические глобальные переменные. Последние статичны "в более широком смысле": они доступны, пока загружен исполняемый модуль (.exe или .DLL). А локальные переменные существуют только во время выполнения функции. Когда функция возвращает управление локальные переменные уже не существуют.

Примечание: строго говоря, хотя локальные переменные действительно исчезают, но память, которые они раньше занимали, не освобождается, а используется заново (re-used) для будущих локальных переменных. Что, впрочем, не означает, что вы должны обращаться к этой памяти после выхода из функции.

Тем не менее, локальные переменные называются "статическими" по следующим соображениям:

1. В коде вызова процедуры или функции нет кода выделения динамической памяти. Его нет даже под капотом языка. Хотя надо сказать, что вызываемый выделяет память сам (на уровне машинного кода). Но делает это он сдвигом вершины стека, а не обращением к VirtualAlloc. Более того, стек не является прямой обёрткой к VirtualAlloc - вся память уже выделена, машинный код просто меняет "данные учёта", сдвигая границу вершины стека.
2. Стек управляется аппаратно - про него (в определённой степени) "в курсе" центральный процессор. Т.е. если все ранее/выше обсуждаемые регионы для процессора были равнозначны (единственное, что его заботит - атрибуты защиты страниц памяти, да разделение на режим ядра и пользователя), то для работы со стеком у процессора есть специальные регистры и команды.
3. Локальные переменные существуют в течение всего времени их "контейнера". Контейнером глобальных переменных является исполняемый модуль. Контейнером локальных переменных является функция или процедура. Глобальные переменные существуют, пока существует исполняемый модуль. Поэтому - они статичны. Локальные переменные существуют, пока существует (выполняющаяся) функция. Именно поэтому они - статичны (по аналогии): потому что они живут в течение всего времени жизни контейнера (и им не нужно ручное выделение/освобождение памяти). Сравните это с динамическими переменными, которые могут:
   1. Жить короче времени жизни контейнера - вы можете создать и удалить динамические данные только на коротком участке кода процедуры; на прочем коде процедуры динамическая переменная (её данные) не будет существовать.
   2. Жить "многократно" - вы можете многократно создавать и удалять одну или несколько динамических переменных в одной и той же процедуре.
   3. Жить после "смерти" контейнера - вы можете создать динамические данные и передать их вызывающему. Заметьте, что вы не можете сделать это со статическими переменными (но вы можете дать вызывающему их скопировать).

Ладно, вроде со "статическим" понятно: данные статичны "локально" - на время работы функции. Но что насчёт выделения памяти: откуда она берётся?

Как я уже сказал выше: система резервирует под стек потока регион и выделяет в нём лишь две страницы памяти, а также устанавливает указатель стека на его вершину - на конец страницы, с которой поток начнет использовать свой стек. Вторая страница сверху называется сторожевой (guard page) и имеет специальный атрибут защиты - PAGE_GUARD.

По мере разрастания дерева вызовов (одновременного обращения ко всё большему числу функций) потоку, естественно, требуется и больший объем стека. Как только поток обращается к следующей странице (а она является сторожевой), то процессор возбуждает аппаратное исключение "доступ к сторожевой странице" (это не механизм, специфичный для стека, а вообще для любой страницы с PAGE_GUARD-атрибутом). Система видит это исключение и расширяет стек - та страница, что была сторожевой, становится обычной read-write страницей, а следующая за ней (в сторону младших адресов, т.к. стек растёт в обратную сторону) становится новой сторожевой страницей. Благодаря такому механизму работы, объем памяти, занимаемой стеком, увеличивается только по мере необходимости.

Понятно, что бесконечно стек потока расти не может - рано или поздно он упрётся в ограничение (занятую страницу памяти). В этом случае, когда система видит, что стек расширять уже некуда, она возбуждает исключение EXCEPTION_STACK_OVERFLOW (одновременно передав память под последнюю страницу памяти; страницы с PAGE_GUARD более не будет). Если же ваш поток продолжит использовать стек даже после исключения, связанного с переполнением стека (т.е. исчерпает последние 4 Кб из последней же страницы памяти), то при очередной попытке добавления данных в стек поток выйдет за пределы стека и наткнётся на страницу с доступом PAGE_NOACCESS. Такая страница, память которой никогда не передаётся, всегда ограничивает стек сверху. Поскольку это обычная страница без доступа, то будет возбуждено стандартное исключение Access Violation. Вероятнее всего, вы не сможете его обработать (ведь обработка требует стека). Поэтому ваш процесс будет аварийно завершён.

Кстати говоря, стек умеет только расширяться. Однажды увеличив свой размер, он более не уменьшается. И (ещё "кстати") стек в VMMap показан оранжевым цветом (регионы "Stack").

Библиотека RTL Delphi содержит функцию (точнее - "магию компилятора"), позволяющую контролировать стек. Она обеспечивает корректную передачу страниц физической памяти стеку потока. Возьмем, к примеру, небольшую функцию, требующую массу памяти под свои локальные переменные:

procedure DoSomething;
var
  Buffer: array[0..10240 - 1] of Byte;
begin
  // работа с Buffer, например:
  Buffer[High(Buffer)] := 0;
end;

Для размещения массива Buffer функция потребует минимум 10 Кб стекового пространства. В системе с размером страниц по 4 Кб это могло бы создать проблему. Если первое обращение к стеку проходит по адресу, расположенному ниже сторожевой страницы (как в показанном выше фрагменте кода), то поток обратится к зарезервированной памяти, и возникнет нарушение доступа (вместо обращения к сторожевой странице и расширения стека). Поэтому, чтобы можно было спокойно писать функции, вроде приведенной выше, компилятор и вставляет в генерируемый код специальную конструкцию для контроля стека. Этот код представляет просто цикл, который проходится по стеку с крупным шагом (в страницу) по области текущей функции, "касаясь" (читая) данных стека. В процессе такого "касания" может быть задета сторожевая страница и стек "подрастёт" достаточно, чтобы вместить все локальные данные процедуры.

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

Прочие регионы

Осталось только упомянуть, что память в адресном пространстве выделяете не только вы (ваша программа), но и система. К примеру, система хранит блоки переменных окружения процесса и его потоков. Другой пример - работа с любыми "не ядерными" объектами. К примеру, обращение к подсистемам User и GDI может выделять память в адресном пространстве процесса для хранения служебных данных объектов User или GDI. Тут важно понимать, что в этом случае система ничем не отличается от вашей программы - она ведёт себя точно так же как вы. Она является как бы составной частью вашей программы. Это в том смысле, что система не использует какие-то "секретные места", а выделяет память в динамической памяти или куче - ровно как и вы (конечно же, система не использует менеджер памяти Delphi - она использует какой-то из своих менеджеров). Т.е. она выступает как простой набор сторонних библиотек, ничем не отличающихся от любых других библиотек сторонних производителей (или даже ваших DLL).

Прочие важные понятия

Статические и динамические данные

В общем-то, я уже сказал большую часть слов. Данные и переменные делятся на статические и динамические. Статические:

• Автоматическое управление памятью: всегда доступны на время жизни контейнера.
• Имеют фиксированный размер.
• Имеют фиксированное количество.
• Могут иметь ограничения на размер (локальные данные не могут быть больше размера стека).
• Не могут генерировать утечки памяти (поскольку уходят вместе с контейнером).
• Переменная = данные.
• Могут быть локальными и глобальными.

Динамические:

• Ручное управление памятью: вы должны явно выделить память перед использованием переменной и явно освободить, когда переменная больше не нужна.
• Могут иметь фиксированный и произвольный (динамический) размер.
• Могут иметь произвольное количество элементов.
• Не имеют ограничений на размер, за исключением естественных.
• Могут создавать утечки памяти, если вы забудете освободить память.
• Переменная = указатель. Данные находятся по указателю.
• Могут быть локальными и глобальными.

Например, к статическим данным относятся:

• Integer, Char, Extended, Boolean и другие простые типы.
• Перечислимые типы и тип-диапазон (вообще-то, это тоже простые типы).
• Статические массивы (array[0..5] of Integer).
• Множества.
• Процедурный тип
• Записи
• Классические объекты Паскаля (T = object, аналог записей).
• Файлы ("паскалевские" file и textfile).
• Паскалевские строки ("короткие строки": ShortString и String[20]).
• и т.п.

К динамическим:

• Строки (String, AnsiString, WideString, UnicodeString).
• Указатели: типизированные (PInteger, PRecord и др.) и нетипизированные (Pointer).
• Динамические массивы (array of Integer).
• Объекты (T = class, аналог указателя на запись).
• Интерфейсы (T = interface, аналог указателя на запись с полями из процедурного типа).
• Варианты (Variant).
• и т.п.

Это не полный список. Я мог кого-то забыть. Кроме того, здесь не указаны составные типы (пользовательские типы данных).

Управляемые и неуправляемые данные

Если вы сравнивали список характеристик динамических переменных со списком динамических типов данных в предыдущем пункте, то могли увидеть небольшую нестыковку:

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

"Гм, когда это я выделял память под строки?"

Хороший вопрос. Дело в том, что динамические типы данных дополнительно делятся ещё на две категории: неуправляемые и управляемые (также иногда называемые авто-финализируемыми, автоматическими, авто-управляемыми, ссылочными или типами с автоматическим управлением временем жизни). Неуправляемые типы данных - это:

• Указатели
• Объекты

Они характеризуются тем, что вы должны сами явно создавать и удалять их.

Прочие типы (строки, динамические массивы, интерфейсы, варианты) относятся к управляемым типам. Хотя вы всё ещё должны создавать и удалять их, но если вы этого не сделаете (не удалите), то за вас эту операцию выполнит компилятор. Иными словами, операции освобождения памяти всё ещё есть, но для управляемых типов они скрыты под капотом языка. Автоматические типы "притворяются" простыми статическими типами, хотя на самом деле являются динамическими типами. Это - большой источник подводных камней для новичков, которые пытаются обращаться с этими типами как с простыми статическими - что далеко не всегда возможно (вспомните про "переменная" <> данные). Конечно же, ничто не мешает вам явно освобождать память - и иногда это необходимо делать, хотя и очень редко: например).

Чтобы знать, когда необходимо удалять память переменной, компилятор отслеживает её время жизни: когда переменная уходит из области видимости (к примеру: завершается процедура, чью локальную переменную отслеживает компилятор). Кроме того, почти для всех автоматических типов компилятор использует дополнительный механизм: счётчик ссылок. Суть его заключается в том, что на одни и те же данные может ссылаться несколько переменных. К примеру, если у вас есть строка, а вы присваиваете её второй переменной, то в действительности вы не создаёте две строки - просто для данных строки увеличивается счётчик ссылок. Для каждой добавляемой ссылки (т.е. при присваивании, передаче как параметр в подпрограмму и т.п.) увеличивается счётчик ссылок, а для каждой удаляемой ссылки (т.е. когда переменная выходит из области видимости, при пере-присваивании или присваивании nil) счётчик уменьшается. Данные удаляются, когда счётчик опускается до 0.

Замечание: с определённой точки зрения можно сказать, что статические переменные относятся к управляемым типам данным - ведь память под них вручную вы тоже не распределяете. Однако в этом смысле термин "управляемый тип данных" употребляется крайне редко.

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

Адреса возврата

Но это ещё не всё. Хотя мы полностью разобрали все "наши" данные в нашей программе, остались кой-какие служебные данные, о которых стоит сказать в этой статье.

Вы не задумывались, как происходит вызов функций? Ну, т.е. мы уже поняли, что в адресном пространстве процесса выделен 1 Мб под стек. Мы вызываем процедуру - в стеке создаются её локальные переменные. Это да. Но вопрос: как процессор возвращает управление из процедуры? Ну, с вызовом всё понятно: в коде просто находится инструкция "вызвать код по адресу XYZ". А что с возвратом? Ведь нужно вернуть управление туда, где мы были до вызова - а ведь это не фиксированное место.

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

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

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

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

Некоторые части, показанные на рисунке, могут отсутствовать в конкретном случае (аргументы, собственные локальные переменные и сброшенные (spilled) регистры), другие являются обязательными (адрес возврата). Точное размещение и порядок этих данных не фиксирован и зависит от модели вызова (также называемой соглашением вызова) - это контракт, соглашение, которому соглашаются следовать вызываемый и вызывающий, чтобы успешно взаимодействовать и понять друг друга. Некоторые общеизвестные модели вызова в Delphi: register, stdcall, cdecl. Очевидно, что если вызывающий будет использовать не то соглашение вызова, что вызываемый - они друг друга не поймут. На том месте, где вызываемый ожидает увидеть (к примеру) свои аргументы будет что-то другое. Это может привести к куче плохих вещей, но иногда это может даже работать.

Ну, хорошо: в стеке хранятся адреса возврата и нам лучше бы не перепутать модель вызова функции при её импорте из DLL. Что ещё?

Видите-ли, проблема тут в том, что данные "разного уровня" (ваши и служебные) хранятся в одном месте (стеке). Смотрите: вот есть режим ядра и режим пользователя. Есть страницы памяти для чтения-записи, а есть для чтения-выполнения. Во всех этих случаях выполняется некий "божественный" контроль. "Божественный" - в том смысле, что происходит он вне "текущего мира", над ним. За программной частью следит аппаратный уровень. Что это значит? Это значит, что если ты ошибёшься, если напортачишь или, даже, специально умыслишь недоброе - ничего страшного не произойдёт. Напакостить тебе никто не даст: между тобой и служебными данными стоит непроницаемая стена аппаратного разграничения. Ты не можешь её обойти на программном уровне, для этого надо подняться на уровень выше. Иными словами, здесь система гарантирует целостность служебных данных.

С другой стороны, служебные и прикладные данные в стеке не разграничиваются вообще никак: они просто идут сплошным потоком. Одно отличается от другого только по "намёкам" в виде того, что "программа знает", что "вот конкретно сейчас ровно на 16 байт от вершины стека лежит адрес возврата". Согласитесь, весьма шаткая грань, верно?

И это действительно так. Если вы будете неаккуратны, то вы можете задеть и испортить служебные данные. Представьте, что будет, если вы случайно запишете в локальную переменную (скажем: статический массив) больше данных, чем его размер - тогда вы запишете данные "за массив" и можете перезаписать при этом адрес возврата. И тогда, когда функция завершит работу и соберётся вернуть управление тому, кто её вызвал, она перейдёт не к вызывающему, а по совершенно мусорному адресу - тому, что вы записали вместо адреса возврата. В этом, кстати, и заключается смысл атак типа "переполнение буфера" (buffer overflow) - злоумышленник ищет в вашей программе ошибку, место, где вы не проверяете размер данных, чтобы подсунуть вам ложный адрес возврата и перейти не к случайному месту, а вполне конкретному - на код злоумышленника.

Фреймы обработчиков исключений

Здесь всё аналогично предыдущему пункту: кроме вызовов процедур и функций, в стек заносит фреймы ещё и механизм обработки исключений. К примеру:

begin
  ...
  // Установка нового фрейма (push)
  try
    ...
  // Удаление фрейма (pop)
  except
    ...
  end;
  ...
end;

Конечно, фрейм обработчика исключения - не то же самое, что фрейм вызова, но он имеет похожий смысл и структуру. К примеру, там тоже есть ссылка на предыдущий фрейм (обработчика исключения).

И если порча адреса возврата ещё может быть не фатальна: да, вы перейдёте в мусорное место, но вы почти сразу же схлопочите исключение - оно будет поймано обработчиком и вы "откатитесь" к какому-то предыдущему стабильному состоянию. Да, это возможно не всегда, но тем не менее, часто программа может продолжать выполнение после повреждения адреса возврата.

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

Порча памяти

Как вы уже поняли, порча стековой памяти - это может быть очень плохо. Если вы читали мой блог ранее, то можете помнить этот цикл статей по проблемам с памятью. Там я говорил много всего про всевозможные проблемы с памятью - и access violation, и утечки памяти и повреждение памяти (memory corruption), но я достаточно мало сказал там про повреждения стековой памяти. И на это есть простая причина: диагностировать их - обычно очень сложно, если только вам не повезло наткнуться на тривиальный случай (напутали с моделью вызова и т.п.).

Смотрите сами: если данные динамические (выделяются в куче или динамической памяти), то поймать их порчу можно многими способами: мы можем вставить защитные данные до и после блока памяти (и проверять их целостность - уж не вышел ли кто за размер данных переменной и не перезаписал ли данные вне блока памяти), мы можем проверять контрольную сумму данных, мы можем менять атрибуты защиты (и попробуй испорть мои данные под защитой "read only" атрибута! Или даже PAGE_GUARD). В общем, есть куча вещей, просто вагон и маленькая тележка, которые вы можете сделать с динамическими данными. Что ещё более важно: многие проверки могут быть автоматизированы.

Но это совершенно не так для данных на стеке. Фактически, у нас есть 0 (ноль) инструментов для диагностики проблем со стеком!

Надо заметить, что это вовсе не обязательно должно быть так: другие компиляторы имеют (отладочные) опции, позволяющие вставлять аналоги guard-блоков от динамической памяти и в стек. Но вот Delphi такой возможности не имеет.

Ещё надо заметить, что хранение служебных и пользовательских данных в одном месте - это не нерушимое условие. Это так только на архитектуре x86 (x86-32 и x86-64). Другие аппаратные платформы могут реализовывать этот момент по-разному: как похожим, так и совершенно другим способами. К примеру, платформа IA-64 (Intel Itanium), как более молодая платформа, существенно совершеннее технологически. В частности, у IA-64 два стека: один - программный, для пользовательских данных; второй - регистровый, для служебных данных. Таким образом, на этой платформе, хотя переполнение буфера и возможно, но совершенно безопасно для адресов. К сожалению, все эти вкусности нам пока не светят и мы вынуждены работать на этой странной архитектуре x86.

To stack or not to stack?

В связи с этим мне хотелось бы завершить этот цикл кратким сводом правил для новичков: когда следует и когда не следует размещать данные в стеке (читай: делать статическими переменными или делать динамическими переменными):

• В стеке можно размещать простые типы данных: Integer, Char, записи (если они не включают поля из типов, не рекомендованных к размещению на стеке), перечислимые типы и т.п.
• Любые массивы (даже статические) надо размещать в динамической памяти.
• Любые "buffer-like" данные, доступ к которым происходит через низкоуровневые процедуры вроде Move, FillChar и т.п. - надо размещать в динамической памяти.

Замечу, что это рекомендации с точки зрения "защитного программирования". Если вы руководствуетесь другими соображениями, то вы можете использовать и другие правила. Но для новичков, как мне представляется, наибольшую ценность имеет именно подход защитного программирования. Я понимаю, что некоторые правила могут показаться как явный overkill. Да, для опытного программиста это определённо так. Но для начинающего, что лучше: включить отладочный режим в менеджере памяти и найти проблему (в динамической памяти) или полгода искать причину вылета программы из-за повреждения стека?

Но в любом случае, если человек точно уверен, что он не напортачит с данными, то можно использовать и такой подход:

• Все данные "больших размеров" (близко к размеру страницы и более; т.е. где-то >= 4 Кб) имеет смысл размещать динамически.
• Листовые функции (т.е. функции которые не вызывают другие) могут размещать в стеке больше данных, чем прочие.
• Часто вызываемые, высокоуровневые и рекурсивные функции должны стремиться минимизировать размеры данных на стеке.
• Функции, которые потенциально могут получать управление во время обработки stack overflow (в частности - все обработчики исключений и вызываемые из них функции), должны максимально минимизировать нагрузку на стек.

В общем, суть сводится к тому, что большие данные допустимы на стеке только для простых функций (листовые). В остальных случаях на стеке лучше помещать только простые локальные переменные, а большие данные выгружать в динамическую память.

Разумеется, и это не является истиной в последней инстанции. Рассматривайте этот список как предложение, рекомендации.

Последнее, о чём я хотел бы сказать - передача статических данных больших размеров в функции (как правило - массивов):

type
  TArray = array[0..1024 * 1024 - 1] of Byte;

procedure Test1(Arr: TArray);
procedure Test2(const Arr: TArray);

Вспомните, что аргументы функции - это тоже локальные переменные. Вспомните также, что размер стека ограничен 1 Мб (хотя вы и можете поднять этот предел в опциях проекта). Откуда следует, что передача большого статического массива в процедуру - может быть не самой удачной идеей.

Самое предпочтительное при работе с данными больших размеров - сделать их динамическими. Да, даже если вы работаете с данными фиксированного размера. Всё равно - сделайте их динамическими. Это снизит нагрузку на стек.

Если это невозможно или вы не хотите это делать (найду и заставлю чистить картошку на подводной лодке! шучу), то хотя бы используйте модификатор const как у Test2 в примере выше: это передаст массив по ссылке. Если модификатор не указан, то массив передаётся так: в процедуре выделяется локальная переменная того же размера, что и аргумент, и в неё копируется аргумент целиком, после чего в процедуре вся работа происходит уже с этой локальной копией массива. Как несложно догадаться, такое копирование массива при каждом вызове функции - дело не только медленное, но и грозящее переполнением стека, ибо... не резиновый он.

В случае же передачи массива через const локальная копия внутри процедуры не создаётся, а процедура использует переданный ей массив напрямую. При этом модификация массива запрещена.

Если вам всё же нужна модификация массива - используйте модификатор var вместо const. Разумеется, в этом случае все изменения, сделанные внутри процедуры, будут видны и вызывающему.

Или... просто используйте динамические массивы!