Рихтер Дж., Назар К. - Windows via C C++. Программирование на языке Visual C++ - 2009

440 Часть III. Управление памятью

Физическая память и страничный файл

В старых операционных системах физической памятью считалась вся оперативная память (RAM), установленная в компьютере. Иначе говоря, если в вашей машине было 16 Мб оперативной памяти, вы могли загружать и выполнять приложения, использующие вплоть до 16 Мб памяти. Современные операционные системы умеют имитировать память за счет дискового пространства. При этом на диске создается страничный файл (paging file), который и содержит виртуальную память, доступную всем процессам.

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

С точки зрения прикладной программы, страничный файл просто увеличивает объем памяти, которой она может пользоваться. Если в вашей машине установлено 1 Гб оперативной памяти, а размер страничного файла на жестком диске составляет также 1 Гб, приложение считает, что объем оперативной памяти равен 2 Гб.

Конечно, 2 Гб оперативной памяти у вас на самом деле нет. Операционная система в тесной координации с процессором сбрасывает содержимое части оперативной памяти в страничный файл и по мере необходимости подгружает его порции обратно в память. Если такого файла нет, система просто считает, что приложениям доступен меньший объем памяти, — вот и все. Но, поскольку страничный файл явным образом увеличивает объем памяти, доступный приложениям, его применение весьма желательно. Это позволяет приложениям работать с большими наборами данных.

Физическую память следует рассматривать как данные, хранимые в дисковом файле со страничной структурой. Поэтому, когда приложение передает физическую память какому-нибудь региону адресного пространства (вызывая VirtualAlloc), она на самом деле выделяется из файла, размещенного на жестком диске. Размер страничного файла в системе — главный фактор, определяющий количество физической памяти, доступное приложениям. Реальный объем оперативной памяти имеет гораздо меньшее значение.

Теперь посмотрим, что происходит, когда поток пытается получить доступ к блоку данных в адресном пространстве своего процесса. А произойти может одно из двух (рис. 13-2).

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

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

Глава 13. Архитектура памяти в Windows.docx 441

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

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

Рис. 13-2. Трансляция виртуального адреса на физический

442 Часть III. Управление памятью

Физическая память в страничном файле не хранится

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

Однако система действует не так, иначе на загрузку и подготовку программы к запуску уходило бы слишком много времени. На самом деле происходит вот что: при запуске приложения система открывает его исполняемый файл и определяет объем кода и данных. Затем резервирует регион адресного пространства и помечает, что физическая память, связанная с этим регионом, — сам ЕХЕ-файл. Да-да, правильно: вместо выделения какого-то пространства из страничного файла система использует истинное содержимое, или образ (image) ЕХЕ-файла как зарезервированный регион адресного пространства программы. Благодаря этому приложение загружается очень быстро, а размер страничного файла удается заметно уменьшить.

Образ исполняемого файла (т. е. EXEили DLL-файл), размещенный на жестком диске и применяемый как физическая память для того или иного региона адресного пространства, называется проецируемым в память файлом (memorymapped file). При загрузке EXE или DLL система автоматически резервирует регион адресного пространства и проецирует на него образ файла. Помимо этого, система позволяет (с помощью набора функций) проецировать на регион адресного пространства еще и файлы данных. (О проецируемых в память файлах мы поговорим в главе 17.)

Примечание. Windows может использовать несколько страничных файлов, и, если они расположены на разных физических дисках, операционная система работает гораздо быстрее, поскольку способна вести запись одновременно на нескольких дисках. Чтобы добавить или удалить страничный файл, откройте в Control Panel аплет System, щелкните ссылку Advanced, Adjust The Appearance And Performance Of Windows. На вкладке Advanced

щелкните в секции Virtual Memory кнопку Change. На экране появится следующее диалоговое окно:

444 Часть III. Управление памятью

Табл. 13-3. Атрибуты защиты страниц памяти

Некоторые вредоносные программы записывают код в области памяти, предназначенные для хранения данных (например, в стек потока), а затем исполняют его. Для защиты от подобных атак предназначен механизм Windows, названный Data Execution Prevention (DEP). Если DEP включен, система назначает атрибуты PAGE_EXECUTE_* только тем регионам памяти, в которых хранится предназначенный для исполнения код. Остальные атрибуты (чаще всего PAGE_READWRITE) назначаются регионам, предназначенных для хранения данных (например, регионам, занятым кучами и стеками потоков). При попытке исполнения кода, хранящегося в странице, не имеющей атрибута защиты PAGE_EXECUTE_*, процессор генерирует исключение «нарушение доступа».

У механизма структурной обработки исключений Windows (см. главы 23-25) защита еще надежнее. При компоновке приложения с ключом /SAFESEH обработчики исключений регистрируются в специальной таблице, хранящейся в файле образа. При вызове обработчика исключений система проверяет, зарегистрирован ли он в таблице, и разрешает исполнение только зарегистрированных обработчиков.

Подробнее о DEP cм. в официальной статье «03_CIF_Memory_Protection. DOC» по ссылке http://go.microsoft.com/fwlink/?LinkId=28022.

Глава 13. Архитектура памяти в Windows.docx 445

Защита типа «копирование при записи»

Атрибуты защиты, перечисленные и предыдущей таблице, достаточно понятны,

кроме двух последних: PAGE_WRITECOPY и PAGE_EXECUTE_ WRITECOPY.

Они предназначены специально для экономного расходования оперативной памяти и места в страничном файле. Windows поддерживает механизм, позволяющий двум и более процессам разделять один и тот же блок памяти. Например, если вы запустите 10 экземпляров программы Notepad, все экземпляры будут совместно использовать одни и те же страницы с кодом и данными этой программы. И обычно никаких проблем не возникает — пока процессы ничего не записывают в общие блоки памяти. Только представьте, что творилось бы в системе, если потоки из разных процессов начали бы одновременно записывать в один и тот же блок памяти!

Чтобы предотвратить этот хаос, операционная система присваивает общему блоку памяти атрибут защиты «копирование при записи» (copy-on-write). Когда

.exe- или .dll-модуль, проецируется в адресное пространство процесса, система подсчитывает число страниц, доступных для записи (хранящие код страницы обычно помечаются атрибутом PAGE_EXECUTE_READ, а страницы, хранящие данные — атрибутом PAGE_READWRITE) и выделяет в страничном файле место для соответствующего числа страниц. Однако это место реально используется, только если в эти страницы будет что-то записано.

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

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

2.Скопирует страницу с данными, которые поток пытается записать в общий блок памяти, на свободную страницу оперативной памяти, полученную на этапе 1. Последней присваивается атрибут защиты PAGE_READWRITE ИЛИ PAGE_EXECUTE_READWRITE. Атрибут защиты и содержимое исходной страницы не меняются.

3.Отобразит виртуальный адрес этой страницы в процессе на новую страницу в оперативной памяти.

Когда система выполнит эти операции, процесс получит свою копию нужной

страницы памяти. Подробнее о совместном использовании памяти и о защите типа «копирование при записи» я расскажу в главе 17.

Кроме того, при резервировании адресного пространства или передаче физической памяти через VirtualAlloc нельзя указывать атрибуты PAGE_WRITECOPY или PAGE_EXECUTE_WRITECOPY. Иначе вызов VirtualAlloc даст ошибку, a

GetLastError вернет код ERROR_INVALID_PARAMETER.

446 Часть III. Управление памятью

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

Специальные флаги атрибутов защиты

Кроме рассмотренных атрибутов защиты, существует три флага атрибутов защи-

ты: PAGE_NOCACHE, PAGE_WRITECOMBINE и PAGE_GUARD. Они комби-

нируются с любыми атрибутами защиты (кроме PAGE_NOACCESS) побитовой операцией OR.

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

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

Флаг PAGE_GUARD позволяет приложениям получать уведомление (через механизм исключений) в тот момент, когда на страницу записывается какойнибудь байт. Windows использует этот флаг при создании стека потока. Подробнее на эту тему см. раздел «Стек потока» в главе 16.

Подводя итоги

А теперь попробуем осмыслить понятия адресных пространств, разделов, регионов, блоков и страниц как единое целое. Лучше всего начать с изучения карты виртуальной памяти, на которой изображены все регионы адресного пространства в пределах одного процесса. В качестве примера мы воспользуемся программой VMMap из главы 14. Чтобы в полной мере разобраться в адресном пространстве процесса, рассмотрим его в том виде, в каком оно формируется при запуске VMMap (см. главу 14) под управлением Windows на 32-разрядной процессорной платформе x86. Образец карты адресного пространства VMMap показан в таблице

13-4.

Табл. 13-2. Образец карты адресного пространства процесса в Windows 2000 на 32-разрядном процессоре типа x86

Глава 13. Архитектура памяти в Windows.docx 447

Табл. 13-2. (продолжение)

448 Часть III. Управление памятью

Табл. 13-2. (продолжение)

Глава 13. Архитектура памяти в Windows.docx 449

Табл. 13-2. (продолжение)