Все описанное полностью соответствует понятию загрузки страниц по требованию, описанному в п. 5.5. В качестве особенностей реализации замещения страниц в Windows следует отметить следующее.
· Для каждого процесса в системе определены максимальный и минимальный размер его рабочего множества. При выборе вытесняемой страницы система пытается добиться, чтобы за каждым процессом сохранялось не менее минимального, но не более максимального количества памяти. Это позволяет избежать ситуации, когда один процесс, расточительно использующий память, вытесняет из нее почти все страницы других процессов. Процесс может изменить размеры своего рабочего множества, но при этом суммарные требования всех процессов ограничиваются реальным размером имеющейся памяти.
· Процесс может запереть в памяти некоторый диапазон адресов, чтобы воспрепятствовать вытеснению соответствующих страниц на диск. Суммарный размер памяти, запертой одним процессом, по умолчанию не должен превосходить 30 страниц. Длительное удержание одним процессом большого числа страниц запертыми в памяти привело бы к уменьшению объема памяти, доступного для других процессов (да и для незапертых страниц того же процесса).
5.8.3. Отображение исполняемых файлов
При запуске нового процесса Windows использует практически тот же механизм выделения регионов памяти, который был описан в предыдущем пункте. Отличие в том, что выделение памяти выполняет сама система. Кроме того, нет необходимости в использовании страничного файла, поскольку для хранения страниц, вытесненных на диск, как нельзя лучше подходит сам EXE-файл (или DLL-файл, содержащий разделяемую библиотеку функций). При запуске программы Windows резервирует достаточное количество виртуальных страниц и закрепляет за ними блоки EXE-файла. При этом нет необходимости выполнять такое действие, как «загрузка» программы в традиционном смысле. Чтение кодов программы выполняется по мере необходимости, согласно общему принципу загрузки страниц по требованию.
Как правило, текст программы не подвергается изменениям в ходе ее выполнения. Это означает, что соответствующие виртуальные страницы остаются «чистыми» и при их вытеснении нет необходимости в записи на диск. Если один и тот же исполняемый файл используется одновременно несколькими процессами (что вполне возможно для EXE-файла в случае запуска нескольких экземпляров программы, а для DLL-файлов является правилом), то на один и тот же файл отображаются виртуальные страницы каждого из этих процессов. При этом вполне возможно, что в таблицах страниц разных процессов один и тот же исполняемый файл будет соответствовать разным диапазонам виртуальных адресов.
Проблема возникает в том случае, если по логике работы программы должна выполняться запись в некоторые страницы памяти, соответствующие исполняемому файлу. Это нормальное явление, поскольку в состав EXE-файла могут входить области памяти, отведенные для статических переменных программы. Очевидно, нельзя позволить программе изменять свой собственный файл только потому, что изменились значения переменных. Тем более, если файл используется сразу в нескольких процессах и в каждом из них переменные принимают разные значения. Выход, используемый WindowsNT в этой ситуации, заключается в следующем. Все виртуальные страницы, соответствующие выполняемому файлу, выделяются со специальным атрибутом доступа PAGE_WRITECOPY, т.е. «копирование при записи». Пока процессы только читают данные из этих страниц, все происходит, как описано выше. Если же процесс пытается выполнить запись на страницу с таким атрибутом, то происходит прерывание, которое система обрабатывает следующим образом. В страничном файле выделяется блок, в который копируется содержимое данной страницы из EXE-файла. В таблице страниц помечается, что эта виртуальная страница теперь закреплена не за EXE-файлом, а за блоком, выделенным из страничного файла. После этого операция записи успешно выполняется, а при вытеснении страницы она будет сохранена в страничном файле. Таким образом, страничный файл все-таки используется, но только для тех страниц программы, которые изменяются в ходе работы.
Если запускаемый EXE-файл находится на дискете, то система сразу копирует его в страничный файл, поскольку использовать для подкачки страниц такое медленное и ненадежное устройство, как дискетный накопитель, было бы крайне неэффективно.
5.8.4. Файлы, отображаемые на память
Нетрудно понять, что те же средства, которые используются для отображения исполняемого файла на виртуальную память, могут быть применены и к любому другому файлу. В Windows программистам предоставляется возможность создавать и использовать объекты типа «отображение файла» (filemapping).
Работа с таким объектом требует предварительной подготовки. Сначала программа должна создать объект, вызвав функцию CreateFileMapping. Среди параметров этой функции можно отметить:
· хэндл предварительно открытого файла, который будет отображаться на память;
· тип доступа к объекту (только для чтения или и для записи);
· размер объекта;
· имя объекта, которое может использоваться для того, чтобы разные процессы могли работать с одним и тем же объектом «отображение файла».
Функция возвращает хэндл созданного или открытого объекта.
Не втором этапе процесс вызывает функцию MapViewOfFile, передавая ей как параметры хэндл объекта «отображение файла», а также размер участка файла, который должен быть отображен, и смещение начала этого участка от начала файла.
Эта функция возвращает виртуальный адрес, соответствующий началу отображенного участка файла в памяти процесса. Другими словами, оказывается, что заданный участок файла каким-то образом уже очутился в памяти, хотя функция чтения из файла не вызывалась.
На самом деле, конечно, данные из файла еще не находятся в памяти. Просто в таблице страниц отмечено, что за такими-то страницами виртуальной памяти закреплены блоки файла. На сей раз не страничного файла и не EXE-файла программы, а того файла, который использовался при создании объекта «отображение файла». Далее начинает действовать все тот же стандартный механизм загрузки страниц по требованию, т.е. реальное чтение из файла произойдет тогда, когда программа обратится к виртуальным адресам, соответствующим отображенному участку файла.
Из сказанного вытекает, что отображение файла на память представляет собой оригинальный способ работы с файлами, при котором вместо явного чтения и записи данных программа ведет себя так, как если бы файл уже находился в памяти. Это действительно так, но это еще не все.
Если два процесса работают с одним и тем же объектом «отображение файла» и участки файла, которые они отображают в свою память, хотя бы частично пересекаются, то Windows гарантирует, что любые изменения данных, сделанные на этом участке одним процессом, сейчас же становятся доступными другому процессу. Таким образом, два процесса фактически работают с общей областью памяти, как показано на рис. 5‑5.
Рис. 5‑5
С этой точки зрения, отображение файлов можно рассматривать как одно из средств взаимодействия процессов, позволяющее под контролем системы преодолеть изоляцию памяти процессов.
Самое забавное, что файл-то здесь и не обязателен. Если при создании объекта «отображение файла» в качестве хэндла файла указано специальное значение FFFFFFFF16, то Windows связывает страницы памяти с блоками страничного файла. В этом случае объект может использоваться только как средство обмена данными между процессами, без привязки к конкретному файлу. При закрытии объекта «отображение файла» его данные в этом случае не сохраняются.
5.8.5. Стеки и кучи
Описанные выше средства управления памятью, основанные на выделении регионов, представляют собой мощный и красивый инструмент для работы с большими массивами памяти. Однако в практике программирования чаще встречаются прозаические задачи, связанные с использованием небольших участков памяти: вызов функций с передачей им параметров и выделением локальных переменных, создание и освобождение переменных в динамической памяти и т.п. Но зато эти мелкие операции могут выполняться очень много раз. Использовать выделение отдельного региона ради того, чтобы получить 10 – 20 байт памяти, это примерно то же самое, что применять ракетное оружие в борьбе с тараканами. Напомним, что минимальный размер региона равен 4 Кб.
Программисты привыкли, что для размещения параметров и локальных переменных функций используется стек, а выделение участков динамической памяти происходит из «кучи» – специально предназначенной для этого области памяти, управляемой исполняющей системой языка программирования. Оба этих механизма получают поддержку со стороны Windows.
При создании новой нити она получает свой собственный стек, размер которого, если он не указан явно, принимается равным 1 Мб. Эта величина может показаться явно избыточной для большинства программ. Стоит ли системе так швыряться памятью?
На самом деле, выделяется 1 Мб резервированной памяти. Реального расходования ресурсов памяти при этом не происходит, разве что от 2 Гб адресного пространства процесса отщипывается сравнительно небольшой кусочек. Размер «настоящей» памяти, закрепленной за стеком в страничном файле, равен поначалу двум страницам, размещенным в самом конце зарезервированного региона, как показано на рис. 5‑6.