Размер виртуального адресного пространства ос windows

Оперативная память (ОЗУ) является тем компонентом персональных компьютеров, важность которого, при современной архитектуре вычислительных систем, сложно переоценить, и без которого работа их (в силу архитектурных особенностей) не представляется возможной. Было бы интересно посмотреть, как именно ОС управляет доступной ей памятью? Как она распределяет её между загруженными приложениями? Как происходит организация (создание) в памяти нового процесса, как код программы получает управление и как процессу выделяется дополнительная память по запросу, в случае, когда выделенная изначально память заканчивается? Как организовано адресное пространство процесса? Подобные вопросы возникали и продолжают возникать у многих довольно часто, но далеко не на все из них находятся вразумительные ответы.
Поскольку круг вопросов, касающихся оперативной памяти настолько велик, что не может быть освещен в одной статье, здесь мы коснемся лишь части огромного механизма управления памяти в ОС Microsoft Windows, а именно изучим адресное пространство процесса, увидим, что же размещается [системой] в пространстве памяти, выделяемой процессу.

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

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

Адресация на уровне процессора

В первых микропроцессорах компании Intel (архитектуры x86) был доступен единственный режим работы процессора, впоследствии названный реальным режимом. Адресация памяти в процессорах того времени была достаточно простой и носила название сегментной. Суть её заключалась в том, что ячейка памяти адресовалась при помощи двух составляющих: сегмент : смещение (сегмент — область адресного пространства фиксированного размера, смещение — адрес ячейки памяти относительно начала сегмента). Специфика архитектуры упомянутых [первых] микропроцессоров накладывала ограничения на размер физического адресного пространства (16 килобайт, 64 килобайта, 1 мегабайт…), и память, доступная программно, была не более размера оперативной (физически установленной) памяти компьютера. Это было просто, логично и понятно. Тем не менее, описанная архитектура имела ряд недостатков, к тому же в индустрии появились тенденции дальнейшего развития:

• Была актуальна проблема согласования выделения памяти различным приложениям. Размещение кода/данных приложений в едином для всех программ пространстве памяти требовало от операционной системы (а иногда и от самой программы) сложного механизма постоянного отслеживания занятого пространства.
• Наметился переход к многозадачным операционным системам, в которых большое количество задач должно было выполняться [псевдо]параллельно, что затрудняло использование общего пространства памяти.
• В условиях множества одновременно выполняющихся задач встала проблема безопасности, необходимости ограничения доступа к «чужим» процессам в памяти.

Эти, а так же некоторые другие, проблемы явились отправной точкой для работы над усовершенствованием, в следствии чего в процессоре 80286 появился защищенный режим и концепция сегментной адресации памяти была значительно расширена для обеспечения новых требований. Например в защищенном режиме сегменты могли располагаться (начинаться) в памяти в произвольном месте (база), иметь нефиксированный размер (лимит), уровни доступа, типы содержимого и прочее. И наконец, по прошествии некоторого времени была создана новая архитектура, получившая название IA-32, в которой были введены несколько новых моделей организации оперативной памяти:

• Базовая плоская модель (basic flat model) — наиболее простая модель памяти [системы], операционная система и приложения получают в своё распоряжение непрерывное, не сегментированное адресное пространство.
• Защищенная плоская модель (protected flat model) — более сложная модель памяти [системы], может применяться страничный механизм изоляции пользовательского/системного кода/данных, описываются четыре сегмента: кода/данных (для уровня привилегий 3, пользовательский уровень) и кода/данных (для уровня привелегий 0, ядро).
• Мульти-сегментная модель (multi-segment Model) — самая сложная модель памяти [системы], предоставляется аппаратная защита кода, данных, программ и задач. Каждой программе (или задаче) назначаются их собственные таблицы [сегментных] дескрипторов и собственные сегменты.

И главным завоеванием защищенного режима явилось появление механизма страничной организации/адресации памяти.

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

Механизм трансляции адресов (преобразование адреса)

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

..и проходит через некоторое количество преобразований, начиная от декодирования инструкции процессором и заканчивая выставлением адреса на шину. Давайте посмотрим, какие же этапы проходит преобразование адреса:

1. Эффективный адрес — адрес, задаваемый в аргументах машинной инструкции при помощи регистров, смещений, коэффициентов. Фактически эффективный адрес представляет собой смещение от начала сегмента (базы). Как раз для нашего примера (выше): эффективный адрес = EDI + ECX * 4 + 4;
2. Логический адрес – адрес, представляющий собой пару селектор : смещение. Традиционно селектор (левая часть) располагается в сегментном регистре, смещение (правая часть) в регистре общего назначения или указывается непосредственно, для нашего примера это: DS:[EDI+ECX*4+4]. Как мы видим, часто сегментный регистр (левая часть) не указывается (выбирается неявно). Фактически с логическими адресами и имеет дело программист в своих программах;
3. Линейный адрес — это 32-/64-разрядный адрес, получаемый путем использования селектора (содержащегося в левой части виртуального адреса, в сегментном регистре, для нашего примера задан неявно, в DS) в качестве индекса в таблице дескрипторов (для вычисления базы сегмента) и добавления к ней смещения (правая часть виртуального адреса, в нашем случае значение, вычисляемое на основе выражения EDI+ECX*4+4). Линейный адрес = база сегмента + эффективный адрес.
4. Гостевой физический адрес — при использовании аппаратной виртуализации. В случае, когда в системе работают виртуальные машины, физические адреса (получаемые в каждой из них), необходимо транслировать ещё раз.
5. Физический адрес — это финальная часть преобразований адреса внутри процессора. Физический адрес:
   • (для сегментной адресации) полностью совпадает с линейным адресом;
   • (для сегментно-страничной адресации) получается путем преобразования трех частей значения линейного адреса на основании: каталога страниц, таблицы страниц и смещения внутри страницы;

   И наконец этот получившийся физический адрес выставляется на адресную шину процессора; может как совпадать с адресом ячейки оперативной памяти, так и не совпадать с ним;

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

Механизм трансляции страниц (страничное преобразование)

Алгоритмы преобразования линейного адреса в физический (этапы 3 → 5) варьируются в зависимости от множества причин (состояния определенных регистров). В некоторых режимах линейный адрес делится на несколько частей, при этом каждая часть является индексом в специализированной системной таблице (все они расположены в памяти), а число и размер описанных таблиц различаются в зависимости от режима работы процессора. Запись в таблице первого уровня представляет собой адрес начала таблицы следующего уровня, а для последнего уровня — информация о физическом адресе страницы в памяти и её свойствах. Иначе говоря:

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

Соответственно, на данном этапе, мы уже имеем дело уже с разбиением адресного пространства на страницы (определенного размера) или со страничной организацией памяти. Иными словами, мы имеем дело с виртуальной памятью. Процессор как бы делит линейное адресное пространство на блоки (страницы) фиксированного размера (в зависимости от установок — 4Кб, 2Мб, 4Мб), которые уже могут отображаются в физической памяти или на жестком диске. И вот тут стоит обратить внимание на один крайне важный аппаратный механизм:

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

Иными словами, преобразование линейного адреса в физический может закончиться неудачей, если:

• страницы в данный момент нет в физической памяти;
• таблицы не содержат необходимых данных;
• недостаточно прав доступа;

Во всех этих случаях возникает аппаратное событие — так называемое исключение Page Fault (#PF), которое предписывает обработчику исключения произвести дополнительные действия по устранению возникшей проблемы: подгрузить (отсутствующую) страницу с диска (либо скинуть (ненужную) страницу на диск). Как только страница была подгружена, то выполнение прерванного кода продолжится с инструкции, которая вызвала #PF. Именно механизм страничной адресации (преобразования) и позволяет операционной системе организовать виртуальное адресное пространство, о котором речь пойдет далее. К сожалению, подробное описание механизмов преобразования адресов и типов адресации выходит за рамки данной статьи, далее мы переходим к «программному» уровню, то есть непосредственно к механизмам операционной системы.

Адресация на уровне ОС

Сами понимаете, что было бы не совсем корректно называть излагаемое в данной главе некоей «программной» частью адресации в операционной системе, поскольку:

Механизмы, используемые операционными системами, имеют аппаратную поддержку на уровне процессора.

..поэтому операционная система Windows эксплуатирует особенности той архитектуры, на которой она в данный момент функционирует (выполняется) и всего-лишь использует аппаратные механизмы [процессора]. Становится очевидным, что если Windows исполняется на станциях, построенных на базе процессоров архитектуры IA-32, то используется защищенный режим работы процессора. Версии операционной системы Windows для архитектуры IA-32, пользуются механизмом сегментации защищенного режима лишь в минимальном объёме:

• используются всего два уровня привилегий: 0 и 3;
• и из всех доступных способов организации памяти используется защищенная плоская модель со страничной адресацией (protected flat model);

Защищенная плоская модель в Windows имеет свои особенности: память представляется программе [задаче] в виде единого непрерывного адресного пространства (линейное адресное пространство). Код, данные и стек — всё содержатся в этом адресном пространстве, то есть объединены в один физический сегмент.

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

Виртуальная память – стратегия организации памяти [операционной системой], основанная на идее создания единого виртуального адресного [псевдо]пространства, состоящего из физической памяти (ОЗУ) и дисковой памяти (жесткий/твердотельный диск).

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

Размерность адресных пространств

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

Физическое адресное пространство

Итак, размерность физического (процессорного) адресного пространства зависит от особенностей аппаратной архитектуры:

• 32-бита: используются 32-битные указатели (размерность 4 байта), и размер адресного пространства равен 2³² = 4294967296 байт (4 гигабайта, Гб). Шестнадцатеричное представление диапазона: 00000000 — FFFFFFFF.
• 64-бита: используются 64-битные указатели (размерность 8 байт) и размер адресного пространства процесса равен 2⁶⁴ = 18446744073709551616 байт (16 экзабайт, Эб. ~17 миллиардов гигабайт). Шестнадцатеричное представление диапазона: 0000000000000000 — FFFFFFFFFFFFFFFF.

Но это, опять же, теоретическая адресация на основе разрядности.

Линейное адресное пространство

Линейное адресное пространство процесса теоретически могло бы быть идентично физическому адресному пространству, но на практике вступают в действие ограничения операционной системы, которые зависят от: версии операционной системы, [определенных] настроек (флагов) операционной системы и приложений, типа запуска: 32-битное приложение на 32-битной ОС, 32-битное приложение на 64-битной ОС, 64-битное на 64-битной ОС.

• 32-бита: размер линейного адресного пространства процесса равен 4Гб, верхние 2Гб (или 1Гб, в зависимости от флагов) из которых защищены на уровне страниц. Поэтому для пользовательского приложения в 32-битной ОС определен лимит в 2Гб (или 3, в зависимости от флагов), за пределы которого процесс выбраться не может (без использования специализированных технологий вида AWE).
• 64-бита: размер линейного адресного пространства процесса равен 16Тб или 256Тб, из которых (верхняя) часть защищена на уровне страниц. Поэтому 32/64-битному пользовательским приложениям может быть определен лимит в 2Гб, 4Гб, 8Тб и 128Тб (в зависимости от разрядности/версии/флагов).

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

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

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

Еще раз: код и данные, которые в данный момент обрабатываются/исполняются, физически располагаются в ОЗУ.

Использование страничной организации операционной системой

Получается интересная ситуация: с одной стороны, для каждого процесса в операционной системе Windows выделяется адресное пространство, которое фактически эквивалентно размерности теоретического адресного пространства; с другой стороны размер физически установленной оперативной памяти (ОЗУ) компьютера может быть в разы меньше суммы всех адресных пространств процессов, исполняемых в данный момент в системе. Как нам в подобной ситуации обеспечить нормальное функционирование операционной системы? А очень просто, поскольку:

1. виртуальные адреса суть иллюзия, они могут не ссылаться на физическую память;
2. [в подавляющем большинстве случаев] процесс не использует всё виртуальное адресное пространство, отведенное для него; то есть адресное пространство процесса не обязательно заполнено [под завязку] данными;
3. общие для всех процессов данные могут разделяться множеством процессов (экономия оперативной памяти);
4. не обязательно код и данные всех процессов [постоянно] держать в ОЗУ (экономия оперативной памяти);

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

• подгружать/выгружать неиспользуемые страницы с/на носитель информации (жесткий диск: HDD, SSD);
• проецировать общие страницы [общих ключевых библиотек] в несколько адресных пространств одновременно;

Страницы, которые в определенный промежуток времени не используются, из ОЗУ переносятся (перепроецируются) на любой физический носитель, установленный в системе — в файл (файл подкачки, страничный файл, page file, swap-файл, «своп») либо [в некоторых ОС] в область подкачки (специализированный раздел).
Сопоставлением (отображением) виртуальных адресов на физические адреса ОЗУ или файла подкачки занимается так называемый диспетчер виртуальной памяти (VMM, Virtual Memory Manager).

Диспетчер виртуальной памяти (Virtual memory manager, Kernel-mode memory manager) — модуль ядра ОС Windows, предназначающийся для организации подсистемы виртуальной памяти: создания таблицы адресов для процессов, организации общего доступа к памяти, осуществления защиты на уровне страниц, поддержки возможность отображения файлов на память, распределения физической памяти между процессами, организации выгрузки/загрузки страниц между физической памятью и файлом подкачки, обеспечения всех процессов достаточным для функционирования объемом физической памяти.

Упрощенная схема процесса «отображения» выглядит следующим образом:

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

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

и теперь вы, надеюсь, понимаете, что:

Виртуальный адрес может быть просто не сопоставлен с физической памятью!!

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

• Виртуальная память, доступная программе, напрямую не связана с физической памятью.
• Каждая программа работает в своей виртуальном адресном пространстве. Размер этого пространства может быть больше размера фактически установленной в машине оперативной памяти.
• Адресное пространство [каждого] процесса (программы), исполняющегося в ОС, изолировано [от подобных адресных пространств других процессов].

Когда какая-либо программа обращается к своим данным, которые [в этот момент] отсутствуют в ОЗУ, то функция обработчика страничного нарушения диспетчера виртуальной памяти производит следующие манипуляции:

1. сохраняет в стек адрес инструкции, следующей за инструкцией, вызвавшей #PF;
2. производит поиск свободной (незанятой) физической страницы;
3. создает новый элемент в таблице страниц;
4. подгружает недостающие данные из файла подкачки в ОЗУ;
5. производит проецирование виртуальной страницы на физическую;
6. производит восстановление адреса из стека и выполняет «перезапуск» инструкции (следующей за той, на которой было прервано выполнение);

Все эти процессы происходят на уровне ядра операционной системы, поэтому они «прозрачны» или «неразличимы» для пользовательского приложения (а программисту, в реалиях высокоуровневого программирования, зачастую и вовсе не интересны).
Теперь несколько слов об изоляции или закрытости [адресного пространства] процесса. Виртуальное пространство [каждого] процесса изолировано, или, можно сказать по-другому — процессы отделены друг от друга в своем собственном виртуальном адресном пространстве. Поэтому любой поток в рамках некоего процесса получает доступ только лишь к той памяти, которая принадлежит родительскому процессу. Наглядно, изолированность выражается в том, что некая программа A в своем адресном пространстве может хранить запись данных по условному адресу 12345678h, и в то же время у программы B по абсолютно тому же адресу 12345678h (но уже в его собственном адресном пространстве) могут находиться совершенно другие данные. Изолированность, к тому же подразумевает, что код одной программы (если быть точным, то потока в рамках процесса) не может получить доступ к памяти другой программы (без дополнительных манипуляций). Достоинства виртуальной памяти:

• Упрощается программирование. Программисту больше не нужно учитывать ограниченность памяти, или согласовывать использование памяти с другими приложениями.
• Повышается безопасность. Адресное пространство процесса изолировано.
• Однородность массива. Адресное пространство линейно.

[пример] Виртуальное адресное пространство процесса

Я думаю, после некоторого количества теоретических выкладок, самое время перейти ближе к рассмотрению основной темы статьи. Напомню, что мы будем исследовать структуру памяти 32-битного процесса Windows. Для исследования памяти процесса нам потребуется специализированное программное средство, которое поможет нам увидеть адресное пространство процесса в деталях. Использовать мы будем утилиту VMMap от Марка Руссиновича, отличное приложение, которое выводит подробную информацию по использованию памяти в рамках того или иного процесса. Однако, не обошлось, что называется, и без ложки дегтя. Бытует мнение, что данное ПО отражает карту процесса не достаточно подробно, игнорируя кое-какие структуры памяти, однако, как отправная точка для понимания принципов размещения объектов в памяти вполне нас устроит.
Для практического эксперимента я буду использовать самописный модуль test2.exe, написанный на ассемблере, код которого предельно прост, отображает всего-лишь некоторые оконные элементы и выводит информационное окно перед выходом. В модуле используются (импортируются) функции SetFocus, SendMessageA, MessageBoxA, CreateWindowExA, DefWindowProcA, DispatchMessageA, ExitProcess, GetMessageA, GetModuleHandleA, LoadCursorA, LoadIconA, PostQuitMessage, RegisterClassA, ShowWindow, TranslateMessage, UpdateWindow из библиотек user32.dll и kernel32.dll. Итак, запускаем на исполнение тестовый файл test2.exe а затем, пока приложение исполняется, загружаем программу VMMap, указывая ей открыть наш целевой процесс. Вот что мы наблюдаем:

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

WS (Working Set) — так называемый рабочий набор, то есть множество (массив) страниц физической памяти (ОЗУ), уже выделенных для процесса и использующихся для фактического хранения кода/данных. Когда требуется доступ к каким-либо адресам виртуальной памяти, фактически с этими адресами должна быть связана физическая память (потому что операции чтения/записи/выполнения могут производиться только с физической памятью). Поэтому, когда с данными адресами будет сопоставлена физическая память, она добавляется как раз к рабочему набору процесса (working set).

Ну и необходимо описать все виды типов (type) регионов. Типы регионов у можно наблюдать на карте процесса в столбце Type:

Как Вы видите из карты процесса, всё адресное пространство процесса разбито на множество неких зон различного назначения, называемых регионами. Регионов в адресном пространстве достаточно много. Однако, для начала, давайте посмотрим на «общее» разбиение адресного пространства процесса, дабы возникло понимание, как что и где может размещаться. Разбиение адресного пространства в определенной степени зависит от версии ядра Windows.
Общая концепция разбиения виртуального адресного пространства 32-битных программ:

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

• Находит исполняемый файл (.exe), указанный в параметре функции CreateProcess. В случае каких проблем просто возвращает управление со статусом false.
• Создает новый объект ядра «процесс».
• Создает адресное пространство процесса.
• Во вновь созданном адресном пространстве резервирует регион (набор страниц). Размер региона выбирается с расчетом, чтобы в него мог уместиться исполняемый .exe-файл. Загрузчик образа смотрит на параметр заголовка .exe-файла, который указывает желательное расположение (адрес) этого региона. По-умолчанию = 00400000, однако может быть изменен при компиляции.
• Отмечает, что физическая память, связанная с зарезервированным регионом это сам .exe-файл на диске.
• После окончания процесс проекции .exe-файла на адресное пространство процесса, система анализирует секцию import directory table, в которой представлен список DLL-библиотек (которые содержат функции необходимые коду исполняемого файла) и список самих функций.
• Для каждой найденной DLL-библиотеки производится «отображение», то есть вызывается функция LoadLibrary, которая выполняет следующие действия:
• Резервирует регион в адресном пространстве процесса. Размер выбирается таковым, чтобы в регион мог поместиться загружаемый DLL-файл. Желаемый адрес загрузки DLL указывается в заголовке. Если размер региона по желаемому адрес меньше размера загружаемого DLL, либо регион занят, ядро пытается найти другой регион.
• Отмечает, что физическая память, связанная с зарезервированным регионом это DLL-файл на диске.
• Производится настройка образа библиотеки, сопоставление функций. Результатом этого является заполненная таблица (массив) адресов импортируемых функций, чтобы в процессе работы код обращается к своему массиву для определения точки входа в необходимую функцию.

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

Резервирование (reserving) — операция выделения региона (выделения блока памяти по те или иные нужды).

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

Страница (page) — минимальная единица [объема памяти], используемая системой при управлении памятью (как мы и писали выше).

Размещение в адресном пространстве структур и библиотек

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

Выводы

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

Главная / Операционные системы /
Основы организации операционных систем Microsoft Windows / Тест 9

Эффективное время доступа к памяти является близким к времени доступа к оперативной памяти:
 

Связывание виртуального и физического адресов в ОС Windows обычно осуществляется на этапе…
 

Размер виртуального адресного пространства ОС Windows …
 

В системе виртуальной памяти ОС Windows одна таблица страниц отводится для: 
 

Таблица страниц  позволяет найти… 
 

Для описания регионов в виртуальном адресном пространстве в ОС Windows используются:
 

База данных PFN (page frame number) используется для:
 

Преимущество программной поддержки сегментации по сравнению с аппаратной  состоит в:
 

Регионы в виртуальной памяти создаются:
 

Регион куча создается:
 

Может ли прикладная программа, находясь в непривилегированном режиме, модифицировать виртуальную ячейку памяти по адресу 0x77777777 ?
 

Может ли прикладная программа, находясь в непривилегированном режиме, модифицировать виртуальную ячейку памяти по адресу 0xA7777777 ?
 

Может ли виртуальный адрес иметь значение большее, чем 0xFFFFFFFF ?
 

Может ли прикладная программа создать регион, расположенный между виртуальными адресами 0x11111111 и 0x22222222 ?
 

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

Для выделения памяти в куче используется функция …
 

Для синхронизации потоков, использующих одну и ту же кучу процесса, …
 

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

Структурную обработку исключений менеджер памяти использует для работы со страницами региона…
 

Для приведения в соответствие содержимого файла на диске с содержимым его проекции в памяти используется …
 

Виртуальная память

Всем процессам в операционной системе Windows предоставляется важнейший ресурс – виртуальная память (virtual memory). Все данные, с которыми процессы непосредственно работают, хранятся именно в виртуальной памяти.

Название «виртуальная» произошло из-за того что процессу неизвестно реальное (физическое) расположение памяти – она может находиться как в оперативной памяти (ОЗУ), так и на диске. Операционная система предоставляет процессу виртуальное адресное пространство (ВАП, virtual address space) определенного размера и процесс может работать с ячейками памяти по любым виртуальным адресам этого пространства, не «задумываясь» о том, где реально хранятся данные.

Размер виртуальной памяти теоретически ограничивается разрядностью операционной системы. На практике в конкретной реализации операционной системы устанавливаются ограничения ниже теоретического предела. Например, для 32-разрядных систем (x86), которые используют для адресации 32 разрядные регистры и переменные, теоретический максимум составляет 4 ГБ (2³² байт = 4 294 967 296 байт = 4 ГБ). Однако для процессов доступна только половина этой памяти – 2 ГБ, другая половина отдается системным компонентам. В 64 разрядных системах (x64) теоретический предел равен 16 экзабайт (2⁶⁴ байт = 16 777 216 ТБ = 16 ЭБ). При этом процессам выделяется 8 ТБ, ещё столько же отдается системе, остальное адресное пространство в нынешних версиях Windows не используется.

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

Реализация виртуальной памяти в Windows

Схема реализации виртуальной памяти в 32-разрядной операционной системе Windows представлена на рис.11.1. Как уже отмечалось, процессу предоставляется виртуальное адресное пространство размером 4 ГБ, из которых 2 ГБ, расположенных по младшим адресам (0000 0000 – 7FFF FFFF), процесс может использовать по своему усмотрению (пользовательское ВАП), а оставшиеся два гигабайта (8000 0000 – FFFF FFFF) выделяются под системные структуры данных и компоненты (системное ВАП)^{1Специальный ключ /3GB в файле boot.ini увеличивает пользовательское ВАП до 3 ГБ, соответственно, уменьшая системное ВАП до 1 ГБ. Начиная с Windows Vista вместо файла boot.ini используется утилита BCDEDIT. Чтобы увеличить пользовательское ВАП, нужно выполнить следующую команду: bcdedit /Set IncreaseUserVa 3072. При этом, чтобы приложение могло использовать увеличенное ВАП, оно должно компилироваться с ключом /LARGEADDRESSAWARE.}. Отметим, что каждый процесс имеет свое собственное пользовательское ВАП, а системное ВАП для всех процессов одно и то же.

Виртуальная память делится на блоки одинакового размера – виртуальные страницы. В Windows страницы бывают большие (x86 – 4 МБ, x64 – 2 МБ) и малые (4 КБ). Физическая память (ОЗУ) также делится на страницы точно такого же размера, как и виртуальная память. Общее количество малых виртуальных страниц процесса в 32 разрядных системах равно 1 048 576 (4 ГБ / 4 КБ = 1 048 576).

Обычно процессы задействуют не весь объем виртуальной памяти, а только небольшую его часть. Соответственно, не имеет смысла (и, часто, возможности) выделять страницу в физической памяти для каждой виртуальной страницы всех процессов. Вместо этого в ОЗУ (говорят, «резидентно») находится ограниченное количество страниц, которые непосредственно необходимы процессу. Такое подмножество виртуальных страниц процесса, расположенных в физической памяти, называется рабочим набором процесса (working set).

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

Каким образом процесс узнает, где в данный момент находится требуемая страница? Для этого служат специальные структуры данных – таблицы страниц (page table).

Структура виртуального адресного пространства

Рассмотрим, из каких элементов состоит виртуальное адресное пространство процесса в 32 разрядных Windows (рис.11.2).

В пользовательском ВАП располагаются исполняемый образ процесса, динамически подключаемые библиотеки (DLL, dynamic-link library), куча процесса и стеки потоков.

При запуске программы создается процесс (см. лекцию 6 «Процессы и потоки»), при этом в память загружаются код и данные программы (исполняемый образ, executable image), а также необходимые программе динамически подключаемые библиотеки (DLL). Формируется куча (heap) – область, в которой процесс может выделять память динамическим структурам данных (т. е. структурам, размер которых заранее неизвестен, а определяется в ходе выполнения программы). По умолчанию размер кучи составляет 1 МБ, но при компиляции приложения или в ходе выполнения процесса может быть изменен. Кроме того, каждому потоку предоставляется стек (stack) для хранения локальных переменных и параметров функций, также по умолчанию размером 1 МБ.

В системном ВАП расположены:

• образы ядра (ntoskrnl.exe), исполнительной системы, HAL (hal.dll), драйверов устройств, требуемых при загрузке системы;
• таблицы страниц процесса;
• системный кэш;
• пул подкачиваемой памяти (paged pool) – системная куча подкачиваемой памяти;
• пул подкачиваемой памяти (nonpaged pool) – системная куча неподкачиваемой памяти;
• другие элементы (см. [5]).

Переменные, в которых хранятся границы разделов в системном ВАП, приведены в [5, стр. 442]. Вычисляются эти переменные в функции MmInitSystem (файл basentosmmmminit.c, строка 373), отвечающей за инициализацию подсистемы памяти. В файле basentosmmi386mi386.h приведена структура ВАП и определены константы, связанные с управлением памятью (например, стартовый адрес системного кэша MM_SYSTEM_CACHE_START, строка 199).

Выделение памяти процессам

Существует несколько способов выделения виртуальной памяти процессам при помощи Windows API^{2См. обзор в MSDN «Comparing Memory Allocation Methods» (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366533(v=vs.85).aspx).}. Рассмотрим два основных способа – с помощью функции VirtualAlloc и с использованием кучи.

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

Отметим, что резервируются участки виртуальной памяти по адресам, кратным значению константы гранулярности выделения памяти MM_ALLOCATION_GRANULARITY (файл basentosincmm.h, строка 54). Это значение равно 64 КБ. Кроме того, размер резервируемой области должен быть кратен размеру страницы (4 КБ).

WinAPI функция VirtualAlloc для выделения памяти использует функцию ядра NtAllocateVirtualMemory (файл basentosmmallocvm.c, строка 173).

2. Для более гибкого распределения памяти существует куча процесса, которая управляется диспетчером кучи (heap manager). Кучу используют WinAPI функция HeapAlloc, а также оператор языка C malloc и оператор C++ new. Диспетчер кучи предоставляет возможность процессу выделять память с гранулярностью 8 байтов (в 32-разрядных системах), а для обслуживания этих запросов использует те же функции ядра, что и VirtualAlloc.

Дескрипторы виртуальных адресов

Для хранения информации о зарезервированных страницах памяти используются дескрипторы виртуальных адресов (Virtual Address Descriptors, VAD). Каждый дескриптор содержит данные об одной зарезервированной области памяти и описывается структурой MMVAD (файл basentosmmmi.h, строка 3976).

Границы области определяются двумя полями – StartingVpn (начальный VPN) и EndingVpn (конечный VPN). VPN (Virtual Page Number) – это номер виртуальной страницы; страницы просто нумеруются, начиная с нулевой. Если размер страницы 4 КБ (212 байт), то VPN получается из виртуального адреса начала страницы отбрасыванием младших 12 бит (или 3 шестнадцатеричных цифр). Например, если виртуальная страница начинается с адреса 0x340000, то VPN такой страницы равен 0x340.

Дескрипторы виртуальных адресов для каждого процесса организованы в сбалансированное двоичное АВЛ дерево^{3АВЛ дерево – структура данных для организации эффективного поиска; двоичное дерево, сбалансированное по высоте. Названо в честь разработчиков – советских ученых Г. М. Адельсон Вельского и Е. М. Ландиса.} (AVL tree). Для этого в структуре MMVAD имеются поля указатели на левого и правого потомков: LeftChild и RightChild.

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

2.2.1Архитектура памяти в ос Windows

В ОС Windows каждому процессу выделяется
собственное виртуальное адресное
пространство. Для 32-разрядных процессов
его размер составляет 4 Гб. Соответственно
32-битный указатель может быть любым
числом от 0x00000000 до 0xFFFFFFFF. Всего, таким
образом, указатель может принимать 4
294 967 296 значений, что является количеством
байтов в 4-гигабайтовом диапазоне. Для
64-разрядных процессов размер адресного
пространства равен 16 экзабайтам,
поскольку 64-битный указатель может быть
любым числом от 0x00000000 00000000 до 0xFFFFFFFF
FFFFFFFF и принимать 18 446 744 073 709 551 616 значений,
что равняется16 экзабайтам.

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

В Windows память, принадлежащая
собственно операционной системе, тоже
скрыта от любого выполняемого потока.
Иными словами, ни один поток не может
случайно повредить ее данные. В Windows
98 такой подход реализован частично, и
есть вероятность, что выполняемый поток,
случайно получив доступ к данным
операционной системы, тем самым нарушит
ее нормальную работу. Тем не менее, в
Windows 98, ни один поток не
может получить доступ к памяти чужого
процесса.

Рассмотрим пример. Допустим, что процесс
А в своем адресном пространстве может
хранить какую-то структуру данных по
адресу 0x12345678, и одновременно
у процесса В по тому же адресу — но уже
в его адресном пространстве — может
находиться совершенно иная структура
данных. Обращаясь к памяти по адресу
0x12345678, потоки, выполняемые
в процессе А, получают доступ к структуре
данных процесса А, Но, когда по тому же
адресу обращаются потоки, выполняемые
в процессе В, они получают доступ к
структуре данных процесса В. Иначе
говоря, потоки процесса А не могут
обратиться к структуре данных в адресном
пространстве процесса В, и наоборот.

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

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

Таблица 2.1. Наименование разделов
памяти в Windows

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

Довольно часто в программах, написанных
на С/С++, отсутствует необходимый код
для обработки ошибок. Например, в
следующем фрагменте кода такой обработки
нет:

int* pnSomeInteger
= (int*) malloc(sizeof(int));

*pnSomeInteger = 5;

При нехватке памяти malloc
вернет NULL. Ho код не учитывает
эту возможность и при ошибке обратится
к памяти по адресу 0x00000000 А поскольку
этот раздел адресного пространства
заблокирован, возникнет нарушение
доступа и данный процесс завершится с
сообщением об обращении к недопустимой
области памяти.

Раздел для совместимости с программами
DOS и 16-разрядной Windows размером 4 Мб в
адресном пространстве процесса необходим
Windows 98 для поддержки совместимости с
программами MS-DOS и 16-разрядной Windows.
Обращение к нему из 32-разрядных
Windows-приложений может вызвать непредвиденные
последствия. Вообще говоря, процессор
должен был бы генерировать нарушение
доступа при обращении потока к этому
участку адресного пространства, но
Microsoft не смогла реализовать эту
возможность.

В Windows XP программы для MS-DOS и 16-разрядной
Windows выполняются в собственных адресных
пространствах и 32-разрядные приложения
повлиять на них не могут.

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

В Windows XP сюда загружаются все EXE- и
DLL-модули В каждом процессе эти DLL можно
загружать по разным адресам в пределах
данного раздела, но так делается крайне
редко. На этот же раздел отображаются
все проецируемые в память файлы, доступные
данному процессу

В Windows 98 основные 32-разрядные системные
DLL (Kernel32.dll, AdvAPI32.dll, User32.dll и GDI32.dll) загружаются
в раздел для общих MMF (memory
mapped files
-проецируемых в память файлов), a EXE- и
остальные DLL-модули — в раздел для кода
и данных пользовательского режима.
Общие DLL располагаются по одному и тому
же виртуальному адресу во всех процессах,
но другие DLL могут загружать их (общие
DLL) по разным адресам в границах раздела
для кода и данных пользовательского
режима (хотя это маловероятно). Проецируемые
в память файлы в этот раздел никогда не
помещаются

Реально используемый приложением объём
виртуальной памяти несколько меньше.
Остальное пространство резервируется
системой. Это пространство нужно системе
для кода ядра, драйверов устройств,
кэш-буферов ввода-вывода, областей
памяти, не сбрасываемых в файл подкачки,
таблиц, используемых для контроля
страниц памяти в процессе и т.д. Такой
подход свойственен системам с большим
монолитным ядром.

Увеличение размера ПО привело к
необходимости увеличения адресного
пространства выделяемого для процесса.
Особенно остро данная проблема встала
для серверных ОС. Как один из вариантов
её решения в версиях Windows 2000 Advanced Server и
Windows 2000 Data Center для процессоров x86
предусмотрена возможность увеличения
этого пространства до 3 Гб. Чтобы все
процессы использовали раздел для кода
и данных пользовательского режима
размером 3 Гб, а раздел для кода и данных
режима ядра — объемом 1 Гб, необходимо
добавить ключ /3GB к нужной записи в
системном файле Boot.ini. Как выглядит
адресное пространство процесса в этом
случае, показано в графе «32-разрядная
Windows 2000/XP (на x86 с ключом
/3GB)» таблицы 2.1.

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

Во избежание конфликтов при выполнении
таких приложений в расширенной 3
гигабайтовой среде, система в момент
запуска приложения проверяет, не
скомпоновано ли оно с ключом
/LARGEADDRESSAWARE. Это означает, что приложение
готово к использованию трехгигабайтового
адресного пространства пользовательского
режима. А если нет, операционная система
резервирует область памяти размером 1
Гб в диапазоне адресов от 0x80000000 до
0xBFFFFFFF. Это предотвращает выделение
памяти по адресам с установленным
старшим битом.

При использовании ключа /3GB
уменьшается количество потоков, стеков
и других ресурсов, которые система могла
бы предоставить приложению. Кроме того,
система в этом случае способна
задействовать максимум 16 Гб оперативной
памяти против 64 Гб в нормальных условиях
— из-за нехватки виртуального адресного
пространства для кода и данных режима
ядра, необходимого для управления
дополнительной оперативной памятью.

Флаг LARGEADDRESSAWARE в исполняемом файле
проверяется в тот момент, когда
операционная система создает адресное
пространство процесса. Для DLL этот флаг
игнорируется При написании DLL
разработчик должен сам обеспечить их
корректное поведение в трехгигабайтовом
разделе пользовательского режима.

Закрытый раздел размером 64 Кб заблокирован,
и любая попытка обращения к нему приводит
к нарушению доступа. Этот раздел
резервируется для упрощения внутренней
реализацию ОС. Вспомните, когда Вы
передаете Windows-функции адрес блока
памяти и его размер, то она (функция),
прежде чем приступить к работе, проверяет,
действителен ли данный блок. Например:

BYTE bBuf[70000];

DWORD dwNumBytesWritTen;

WriteProcessMemory(GetCurrentProcess(), (PVOID)
0x7FFEEE90, bBuf, sizeof(bBuf), &dwNumBytesWritten);

В случае функций типа WriteProcessMemory область
памяти, в которую предполагается запись,
проверяется кодом, работающим в режиме
ядра, — только он имеет право обращаться
к памяти, выделяемой под код и данные
режима ядра (в 32-разрядных системах —
по адресам выше 0x80000000). Если по этому
адресу есть память, вызов WriteProcessMemory,
показанный выше, благополучно запишет
данные в ту область памяти, которая, по
идее, доступна только коду, работающему
в режиме ядра. Чтобы предотвратить это
и в то же время ускорить проверку таких
областей памяти, Microsoft предпочла
заблокировать данный раздел, и поэтому
любая попытка чтения или записи в нем
всегда вызывает нарушение доступа.

Раздел для общих MMF (только Windows 98). В этом
разделе размером 1 Гб система хранит
данные, разделяемые всеми 32-разрядными
процессами. Сюда, например, загружаются
все системные DLL (Kernel32.dll, AdvAPI32 dll, User32.dll
и GDI32 dll), и поэтому они доступны любому
32-разрядному процессу. Кроме того, эти
DLL загружаются в каждом процессе по
одному и тому же адресу памяти. На этот
раздел система также отобра-жает все
проецируемые в память файлы.

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

В 64-разрядной Windows 2000 раздел пользовательского
режима (4 Тб) выглядит непропорционально
малым по сравнению с 16 777 212 Тб, отведенными
под раздел для кода и данных режима
ядра. Дело не в том, что ядру так уж
необходимо все это виртуальное
пространство, просто 64-разрядное адресное
пространство настолько огромно, что
его большая часть не задействована.
Система разрешает нашим программам
использовать 4 Тб, а ядру — столько,
сколько ему нужно. К счастью, какие-либо
внутренние структуры данных для
управления не-задействованными частями
раздела для кода и данных режима ядра
не требуются.

В Windows 98 данные, размещенные в этом
разделе, увы, не защищены — любое
приложение может что-то считать или
записать в нем и нарушить нормальную
работу операционной системы.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

The memory management in the operating system is to control or maintain the main memory and transfer processes from the primary memory to disk during execution. Memory management keeps track of all memory locations, whether the process uses them or not. Determines how much memory should be allocated to each process. Specifies how much memory each process should be given. It decides which processes will be remembered and when. It tracks when memory is released or when it is shared and changes the status accordingly.

Windows Memory Management

Microsoft Windows has its own virtual address space for each 32-bit process, allowing up to 4 gigabytes of memory to be viewed. Each process has 8-terabyte address space on 64-bit Windows. All threads have access to the visible address space of the process. Threads, on the other hand, do not have access to the memory of another process, which protects one process from being damaged by another.

Architecture for 32-bit Windows: The automatic configuration of the 32-bit Windows Operating System (OS) allocates 4 GB (232) of accessible memory space to the kernel and user programs equally. With 4 GB physical memory available, the kernel will receive 2 GB and the app memory will receive 2 GB. Kernel-mode address space is shared by all processes, but application mode access space is provided for each user process.

Architecture for 64-bit Windows: The automatic configuration of the 64-bit Windows Operating System (OS) allocates up to 16 TB (254) of accessible memory space to the kernel and user programs equally. As 16 TB real memory is available, the kernel will have 8 TB of virtual address (VA) space and user application memory will have 8 TB of VA space. Visible address space in the kernel is allocated for all processes. Each 64-bit functionality gets its place, but each 32-bit system works on a 2 GB (Windows) virtual machine.

Virtual Address Space

The process’ visible address space is the range of memory addresses that you can use. The address area of ​​each process is private, and can only be accessed through other processes if it is shared.

A virtual address does not reflect the actual location of an object in memory; instead, the system stores a table for each process, which is an internal data structure that converts visible addresses into local addresses. The program converts the virtual address into a local address every time the chain refers to it.

The virtual address area of Windows is divided into two parts: one for process use and the other for system usage.

Virtual Memory Functions

A process can alter or determine the state of pages in its virtual address space using virtual memory functions.

The width of the visible address space is reserved for the process. Although saving address space does not provide material storage, it prevents scope from using other sharing processes. It does not affect other active address spaces for other processes. Page storage reduces unnecessary use of virtual storage while allowing the process of setting aside part of its address space for the flexible data structure. As required, the procedure can provide a physical repository for this area.

Provide a set of cached pages in the address of the process so that only a shared process can access real storage (either RAM or disk).

For the most dedicated pages, specify read/write, read-only, or no access. This differs from the general distribution procedures, which often provide read/write access to the pages.

Release a set of saved pages, making the visible address set accessible for the following call process sharing actions.

We can withdraw a group of committed pages, freeing up portable storage that can be assigned to any process in the future.

To prevent the program from changing pages in the file, lock one or more memory pages bound to the virtual memory (RAM). Find information about a set of pages in a call process or the address space of a specific process. It may change the access protection of a set of pages bound to the physical address of the call process.

Heap Functions

The system provides a default heap for each process. Private heaps can help applications that make frequent allocations from the heap perform better. A private heap is a block of one or more pages in the caller process’s address space. After constructing the private heap, the process manages the memory in it via operations like HeapAlloc and HeapFree.

File Mapping

The association of file content with a piece of visible address space in the process is known as a file map. To track this relationship, the system creates a file map maker (also known as a category object). File view is the physical address area are used for the file content access process. The process may use both input and outgoing sequences (I/O) thanks to the file map. It also allows the process to work effectively with large data files, such as websites, without requiring the entire file to be mapped to memory. Files with a memory map can be used with many processes to exchange data.

The memory management in the operating system is to control or maintain the main memory and transfer processes from the primary memory to disk during execution. Memory management keeps track of all memory locations, whether the process uses them or not. Determines how much memory should be allocated to each process. Specifies how much memory each process should be given. It decides which processes will be remembered and when. It tracks when memory is released or when it is shared and changes the status accordingly.

Windows Memory Management

Microsoft Windows has its own virtual address space for each 32-bit process, allowing up to 4 gigabytes of memory to be viewed. Each process has 8-terabyte address space on 64-bit Windows. All threads have access to the visible address space of the process. Threads, on the other hand, do not have access to the memory of another process, which protects one process from being damaged by another.

Architecture for 32-bit Windows: The automatic configuration of the 32-bit Windows Operating System (OS) allocates 4 GB (232) of accessible memory space to the kernel and user programs equally. With 4 GB physical memory available, the kernel will receive 2 GB and the app memory will receive 2 GB. Kernel-mode address space is shared by all processes, but application mode access space is provided for each user process.

Architecture for 64-bit Windows: The automatic configuration of the 64-bit Windows Operating System (OS) allocates up to 16 TB (254) of accessible memory space to the kernel and user programs equally. As 16 TB real memory is available, the kernel will have 8 TB of virtual address (VA) space and user application memory will have 8 TB of VA space. Visible address space in the kernel is allocated for all processes. Each 64-bit functionality gets its place, but each 32-bit system works on a 2 GB (Windows) virtual machine.

Virtual Address Space

The process’ visible address space is the range of memory addresses that you can use. The address area of ​​each process is private, and can only be accessed through other processes if it is shared.

A virtual address does not reflect the actual location of an object in memory; instead, the system stores a table for each process, which is an internal data structure that converts visible addresses into local addresses. The program converts the virtual address into a local address every time the chain refers to it.

The virtual address area of Windows is divided into two parts: one for process use and the other for system usage.

Virtual Memory Functions

A process can alter or determine the state of pages in its virtual address space using virtual memory functions.

The width of the visible address space is reserved for the process. Although saving address space does not provide material storage, it prevents scope from using other sharing processes. It does not affect other active address spaces for other processes. Page storage reduces unnecessary use of virtual storage while allowing the process of setting aside part of its address space for the flexible data structure. As required, the procedure can provide a physical repository for this area.

Provide a set of cached pages in the address of the process so that only a shared process can access real storage (either RAM or disk).

For the most dedicated pages, specify read/write, read-only, or no access. This differs from the general distribution procedures, which often provide read/write access to the pages.

Release a set of saved pages, making the visible address set accessible for the following call process sharing actions.

We can withdraw a group of committed pages, freeing up portable storage that can be assigned to any process in the future.

To prevent the program from changing pages in the file, lock one or more memory pages bound to the virtual memory (RAM). Find information about a set of pages in a call process or the address space of a specific process. It may change the access protection of a set of pages bound to the physical address of the call process.

Heap Functions

The system provides a default heap for each process. Private heaps can help applications that make frequent allocations from the heap perform better. A private heap is a block of one or more pages in the caller process’s address space. After constructing the private heap, the process manages the memory in it via operations like HeapAlloc and HeapFree.

File Mapping

The association of file content with a piece of visible address space in the process is known as a file map. To track this relationship, the system creates a file map maker (also known as a category object). File view is the physical address area are used for the file content access process. The process may use both input and outgoing sequences (I/O) thanks to the file map. It also allows the process to work effectively with large data files, such as websites, without requiring the entire file to be mapped to memory. Files with a memory map can be used with many processes to exchange data.

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

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

Виртуальная память

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

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

Максимально возможный объем доступной виртуальной памяти зависит от разрядности операционной системы. Так в 32-разрядной системе процесс может адресовать не более 4 гигабайт (2³²) памяти. Для 64-разрядного процесса теоретическое ограничение составляет 16 экзабайт (2⁶⁴), а практически в современных 64-разрядных версиях Windows поддерживается адресное пространство объемом до 16 терабайт.

Примечание. Некоторые 32-разрядные версии Windows Server используют технологию PAE, позволяющую адресовать до 64ГБ памяти. Подробнее о PAE можно узнать здесь.

В отличии от физической, виртуальная память имеет гораздо более гибкие ограничения. Это позволяет одновременно выполняться большому количеству процессов, которые не смогли бы поместиться в физической памяти. Таким образом, основная задача механизма виртуальной памяти — расширение доступной памяти компьютера.

Управление памятью происходит примерно так.

Виртуальное адресное пространство поделено на блоки равного размера, которые называют страницами (pages). Отсюда кстати и название pagefile — страничный файл. Физическая память также поделена на разделы, называемые страничными фреймами (page frames), которые используются для хранения страниц.

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

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

При дефиците физической памяти диспетчер памяти выбирает фреймы, которые можно освободить и переносит их содержимое на диск, в файл подкачки. Принцип переноса такой: когда процесс использовал все выделенные ему фреймы, то при каждом страничном прерывании в этом процессе система удаляет из физической памяти одну из его страниц. Выбор страницы осуществляется по принципу первым пришел — первым ушел (first in, first out, FIFO), т.е. в файл подкачки переносится страница, дольше всех находившаяся в памяти.

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

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

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

Текущие настройки файла подкачки

Посмотреть текущий размер файла можно в оснастке Свойства системы (System Properties). Для этого надо нажать Win+R и выполнить команду sysdm.cpl. Затем перейти на вкладку «Advanced», в поле «Performance» нажать на кнопку «Settings» и в открывшемся окне перейти на вкладку «Advanced».

Здесь указан суммарный размер файла подкачки на всех дисках, а по кнопке «Change» можно перейти к его настройкам.

По умолчанию включено автоматическое управление размером файла подкачки. Это значит, что операционная система создает один файл подкачки pagefile.sys в корне системного диска и устанавливает его размер автоматически, исходя из своих потребностей.

Дамп памяти

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

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

При следующей загрузке системы диспетчер сеанса (Session Manager Subsystem Service, SMSS) инициализирует файл подкачки и проверяет наличие в нем заголовка дампа. Если заголовок есть, то данные копируются из файла подкачки в файл аварийного дампа и делается соответствующая запись в системном журнале.

Соответственно при автоматическом управлении файлом подкачки система ориентируется на настройки создания аварийного дампа памяти, выбирая размер файла в соответствии с типом дампа:

• Полный дамп памяти (Complete memory dump) — в дамп записывается все содержимое оперативной памяти на момент сбоя, поэтому размер файла подкачки должен быть равен размеру физической памяти + 1Мб (для заголовка). Этот тип выбирается по умолчанию при количестве физической памяти меньше 4ГБ;
• Дамп памяти ядра (Kernel memory dump) —  в дамп записывается только память, выделенная для ядра ОС, драйверов устройств и приложений, работающих в режиме ядра. Дамп ядра занимает гораздо меньше места, чем полный дамп, при этом его как правило достаточно для определения причин сбоя. Этот тип дампа выбирается по умолчанию для систем с объемом ОЗУ 4ГБ и более. Минимальный размер файла подкачки должен составлять примерно 1/3 от объема физической памяти;
• Малый дамп памяти (Small memory dump) — мини-дамп, в котором содержатся минимально необходимые данные: стоп-код и описание ошибки, список загруженных драйверов и информация о запущенных в момент сбоя процессах. Этот дамп требует файл подкачки не менее 2Мб;
• Автоматический дамп памяти (Automatic memory dump) — новый тип дампа, появившийся в  Windows 8Server 2012 и более новых. На самом деле это тот же дамп ядра, единственная разница в том, что он позволяет системе динамически управлять размером файла подкачки, выбирая наиболее оптимальный размер.

Настройки дампа памяти находятся в расширенных свойствах системы, в разделе Загрузка и восстановление (Startup and Recovery). Здесь можно один из четырех типов дампа либо совсем отключить его создание.

Даже зная настройки дампа и объем физической памяти, не получится точно сказать, какого размера файл подкачки создаст система. Поэтому я решил немного поэкспериментировать, для чего взял в качестве подопытных 2 системы — клиентскую Windows 8.1 (x64) и серверную Windows Server 2012 R2 и проверил, как размер файла подкачки зависит от объема физической памяти и настроек дампа. Вот что получилось:

Как видите, размер файла напрямую зависит не только от объема ОЗУ и настроек дампа, но и от типа операционной системы. Кроме того, отключение дампа не означает полное отсутствие файла подкачки.

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

Определение необходимого размера файла подкачки

Хотя размером файла подкачки и можно управлять через настройки дампа памяти, однако это не самый прямой способ. Гораздо правильней настроить размер файла вручную. Остается только выяснить, какой размер можно считать достаточным.

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

Оперативно оценить текущее потребление виртуальной памяти можно в Task manager, в разделе Performance (производительность). В поле Commited показано отношение используемой виртуальной памяти к ее общему количеству. В моем примере на компьютере установлено 64Гб оперативной памяти и такого же объема файл подкачки. Текущий объем виртуальной памяти составляет 128Гб, занято 65Гб. Из них 62,4Гб приходятся на оперативную память и 2,6Гб на файл подкачки.

Также для сбора информации можно воспользоваться счетчиками производительности. Счетчики предоставляют больше информации, а также позволяют собрать статистику за определенное время, что позволит более точно определить потребности системы в виртуальной памяти. Нам потребуются следующие счетчики производительности:

Memory, Commited Bytes — этот счетчик показывает, какое количество байт в виртуальной памяти занято текущими процессами. Когда значение Commited Bytes превышает объем физической памяти, система начинает активно использовать файл подкачки;
Memory, Available Bytes — объем свободной физической памяти на компьютере. Этот параметр показывает загруженность оперативной памяти, а чем меньше физической памяти остается, тем активнее система использует файл подкачки.
Memory, Commit Limit — значение, равное сумме объема оперативной памяти и текущего размера файла подкачки. По другому  — максимальное количество виртуальной памяти, которое может быть выделено всем процессам без увеличения размера файла подкачки.
Memory, %Commited Bytes In Use — показывает процент использования виртуальной памяти. Представляет из себя отношение Commited Bytes Commit Limit.
Paging File, %Usage — процент использования файла подкачки, текущее значение.
Paging File, %Usage Peak — процент использования файла подкачки, пиковое значение.

Для более глубокого анализа потребления памяти можно дополнительно использовать такие счетчики:

Memory, Page Faultsec — количество страничных ошибок (прерываний) в секунду при обращении к страницам памяти. Напомню, что страничное прерывание возникает при обращении к странице памяти, которая была выгружена на диск.
Memory, Pagessec — показывает, сколько страниц в секунду было прочитанозаписано в рамках страничного прерывания.  Проще говоря, этот счетчик показывает интенсивность обмена данными между оперативной памятью и файлом подкачки. Представляет из себя сумму счетчиков Pages Inputsec  и Pages Outpitsec.
Process, Working Set — показывает текущее использование физической памяти активными процессами. Значение Total выдает суммарный объем по всем процессам, но можно вывести данные отдельно и по каждому конкретному процессу. Этот счетчик не имеет прямого отношения к файлу подкачки, но может помочь при диагностике проблем с производительностью.

Как видно на примере, 64-гигабайтный файл подкачки реально используется всего на 2-3%. То есть для нормальной работы с избытком хватит файла подкачки размером 4Гб. И это при том, что сервер очень прилично нагружен, для менее загруженного компьютера цифры будут еще меньше.

Отдельно стоит упомянуть о выборе размера файла подкачки для компьютеров с ролью Hyper-V.  Дело в том, что в силу особенностей архитектуры гипервизор не использует файл подкачки для виртуальных машин даже в случае нехватки физической памяти. На серверах Hyper-V файл подкачки нужен исключительно для целей хостовой системы, в которой используется лишь небольшая часть ОЗУ (обычно не более 2-4ГБ). Поэтому создавать файл подкачки, исходя из общего объема физической памяти в данном случае абсолютно бессмысленно.

Настройка

Определив необходимый размер, переходим непосредственно о настройке. Для изменения размера файла подкачки открываем свойства виртуальной памяти и отключаем автоматический выбор размера. Затем в поле «Drive» выбираем логический диск, на котором будет располагаться файл, выбираем опцию «Custom size», указываем начальный и максимальный размер файла подкачки и жмем «Set». Для того, чтобы изменения вступили в силу, после настройки может потребоваться перезагрузка системы.

Для файла подкачки существуют некоторые ограничения:

• Максимальный размер файла может быть не более 16ТБ для 64-битной и не более 4ГБ для 32-битной системы;
• Можно создавать до 16 файлов подкачки, но каждый должен быть расположен на отдельном томе (логическом диске);
• Для возможности создания аварийного дампа памяти необходимо, чтобы файл подкачки (хотя бы один) находился на системном диске.

Для автоматизации процесса настройки можно использовать вот такой PowerShell скрипт (подставив свои значения):

# Disable automatic management for pagefile
$ComputerSystem = Get-WmiObject -Class Win32_ComputerSystem -EnableAllPrivileges
if ($ComputerSystem.AutomaticManagedPagefile) {
$ComputerSystem.AutomaticManagedPagefile = $false
$ComputerSystem.Put()
}
# Set manual size for pagefile
$PageFile = Get-WmiObject -Class Win32_PageFileSetting -EnableAllPrivileges
$PageFile.InitialSize = 4096
$PageFile.MaximumSize = 8192
$PageFile.Put()

Заключение

В заключение некоторые практические советы, которые могут помочь в настройке.

• При ручной настройке необходимо указать начальный и максимальный размер файла. В этом случае система создает файл начального размера, при необходимости увеличивая его до тех пор, пока он не достигнет максимального. При увеличении размера возможна фрагментация файла подкачки, что скажется на его быстродействии. Для борьбы с фрагментацией можно изначально указать начальный и максимальный размер одинаковыми. Тогда система сразу выделит под файл все необходимое место, а статический размер файла исключит возможную фрагментацию в дальнейшем.
• Для увеличения производительности системы файл подкачки можно перенести на другой раздел. Уточню, что переносить файл стоит только на раздел, находящийся на другом физическом диске. Размещение файла подкачки на дополнительном раздел одного и того же диска не приведет к повышению быстродействия. На практике имеет смысл перенос файла подкачки на отдельный SSD-диск, это может дать заметный прирост производительности.
• Еще один теоретический 🙂 способ повысить скорость работы с файлом подкачки — разместить его на отдельном, специально выделенном только под него разделе, для которого установить размер кластера 64Кб (вместо 4Кб по умолчанию). При работе с большими файлами (такими, как файл подкачки) большой размер кластера может повысить производительность файловой системы. Чем больше размер кластера, тем большими блоками читаютсяпишутся данные, соответственно для одинакового объема данных при размере кластера 64Кб потребуется в 16 раз меньше операций чтениязаписи, чем для 4Кб.
• Кое где встречаются советы полностью отключить файл подкачки. Действительно, в отдельных случаях это может дать некоторый прирост производительности, хотя лично я не вижу в этом большой пользы. Как можно убедиться с помощью счетчиков производительности, при наличии свободной физической памяти ОС и так использует файл подкачки по минимуму, поэтому прирост будет незначительный. Если же при отключенном файле подкачки в процессе работы закончится физическая память, то приложение, потребляющее память, будет остановлено, что чревато сбоем в работе и потерей данных. Кроме того, при отсутствии файла подкачки Windows не сможет сохранить дамп памяти в случае сбоя.
• И последнее. Манипуляции с файлом подкачки не особо сильно влияют на производительность системы в целом. Повторюсь, при достаточном количестве физической памяти файл подкачки используется по минимуму. Если же в системе постоянно не хватает памяти и она активно использует файл подкачки, то в первую очередь стоит подумать о расширении физической памяти.

Цель работы: получение практических навыков по использованию Win32 API для исследования памяти Windows

Типы памяти

На рисунке ниже представлена взаимосвязь виртуального адресного пространства процесса с физической и внешней памятью.

Физическая память

Физическая память (Physical memory) — это реальные микросхемы RAM, установленные в компьютере. Каждый байт физической памяти имеет физический адрес (Physical Address), который представляет собой число от нуля до числа на единицу меньшего, чем количество байтов физической памяти. Например, ПК с установленными 64 Мб RAM, имеет физические адреса &Н00000000-&Н04000000 в шестнадцатеричной системе счисления, что в десятичной системе будет 0-67 108 863.

Физическая память (в отличие от файла подкачки и виртуальной памяти) является исполняемой (Executable), то есть памятью, из которой можно читать и в которую центральный процессор может посредством системы команд записывать данные.

Виртуальная память

Виртуальная память (Virtual Memory) — это просто набор чисел, о которых говорят как о виртуальных адресах. Программист может использовать виртуальные адреса, но Windows не способна по этим адресам непосредственно обращаться к данным, поскольку такой адрес не является адресом реального физического запоминающего устройства, как в случае физических адресов и адресов файла подкачки. Для того чтобы код с виртуальными адресами можно было выполнить, такие адреса должны быть отображены на физические адреса, по которым действительно могут храниться коды и данные. Эту операцию выполняет диспетчер виртуальной памяти (Virtual Memory Manager — VMM). Операционная система Windows обозначает некоторые области виртуальной памяти как области, к которым можно обратиться из программ пользовательского режима. Все остальные области указываются как зарезервированные. Какие области памяти доступны, а какие зарезервированы, зависит от версии операционной системы (Windows 9x или Windows NT).

Страничные блоки памяти

Как известно, наименьший адресуемый блок памяти — байт. Однако самым маленьким блоком памяти, которым оперирует Windows VMM, является страница (Page) памяти, называемая также страничным блоком (Page Frame) памяти. На компьютерах с процессорами Intel объем страничного блока равен 4 Кб.

Память файла подкачки

Страничный файл (Pagefile), который называется также файлом подкачки (Swap File) в Windows находится на жестком диске. Он используется для хранения данных и программ точно так же, как и физическая память, но его объем обычно превышает объем физической памяти. Windows использует файл подкачки (или файлы, их может быть несколько) для хранения информации, которая не помещается в RAM, производя, если нужно, обмен страниц между файлом подкачки и RAM.

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

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

Файлы, отображаемые в память

В лабораторной работе ЛАБ_ОС-2 обсуждались файлы, отображаемые в память, там же был приведен пример отображения файла. Любой файл применяется для проецирования виртуальной памяти так же, как для этих целей используется файл подкачки. Фактически единственное назначение файла подкачки — проецирование (Backing) виртуальной памяти.

Поэтому файлы, проецируемые в память подобным образом, называются отображаемыми в память (Memory—Mapped). На предыдущем рисунке изображены именно такие файлы. Соответствующие виртуальные страницы являются спроецированными на файл (File—Backed).

Функция CreateFileMapping объявляется так:

Function CreateFileMapping(hFile: THandle; lpFileMappingAttributes: PSecurityAttributes; flProtect, dwMaximumSizeHigh, dwMaximumSizeLow: DWORD; lpName: PChar): THandle; stdcall;

Function CreateFileMapping; external kernel32 name ‘CreateFileMappingA’;

Она создает объект «отображение файла» (File—Mapping Object), используя дескриптор открытого файла, и возвращает дескриптор этого объекта. Дескриптор может использоваться с функцией MapViewOf File, отображающей файл в виртуальную память:

Function MapViewOfFile(hFileMappingObject: THandle; dwDesiredAccess: DWORD; dwFileOffsetHigh, dwFileOffsetLow, dwNumberOfBytesToMap: DWORD): Pointer; stdcall;

Function MapViewOfFile; external kernel32 name ‘MapViewOfFile’;

Начальный адрес объекта «отображение файла» в виртуальной памяти возвращает функция MapViewOfFile. Можно также сказать, что представление проецируется на файл с дескриптором HFile.

Если параметр HFile, передаваемый функции CreateFileMapping, установлен в -1, то объект «отображение файла» (любые представления, созданные на основе этого объекта) проецируем на файл подкачки, а не на заданный файл.

Совместно используемая физическая память

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

Если файл, такой как DLL, находится в совместно используемой физической памяти, то о нем можно говорить как о совместно используемом.

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

В частности, можно создать такой объект, проецируемый на файл подкачки,

Просто установив параметр hFile функции CreateFileMapping в -1.

Адресное пространство процесса

Каждый процесс Win32 получает виртуальное адресное пространство (virtual address space), называемое также адресным пространством, или пространством процесса (process space), объем которого равен 4 Гб. Таким образом, код процесса может ссылаться на адреса с &Н00000000 по &HFFFFFFFF (или с 0 по 232 — 1 = 4 294 967 295 в десятичной системе счисления). Конечно, так как виртуальные адреса — это просто числа, заявление о том, что каждый процесс получает свое собственное виртуальное адресное пространство, выглядит довольно бессмысленным. (Это все равно, что сказать, что каждый человек получает свой собственный диапазон возраста от 0 до 150).

Тем не менее, это утверждение должно означать, что Windows не видит ни какой взаимосвязи в том, что и процесс А, и процесс В используют один и тот же виртуальный адрес, например &Н40000000. В частности, Windows может сопоставить (или не сопоставить) виртуальным адресам каждого процесса разные физические адреса.

Использование адресного пространства в Windows 9X

На рисунке показана общая схема использования адресного пространства процесса в Windows 9x.

Область А

Как следует из рисунка, Windows 9х резервирует область А, объем которой всего лишь 4 Кб, для того же, что и Windows NT первые 64 Кб памяти, — с целью предупреждения о нулевых указателях. Эта область защищена, и попытка обращения к ней из программы пользовательского режима приводит к ошибке нарушения доступа.

Область В

Данная область памяти используется для поддержания совместимости с приложениями DOS и 16-разрядными приложениями Windows. Несмотря на потенциальную доступность, она не должна использоваться для программирования.

Область С

Область С — это адресное пространство, используемое прикладными программами и их DLL. Здесь размещаются также и модули Windows. Например, если приложению требуется управляющий элемент OCX, его модуль будет находиться в этой области.

Область D

Windows 9х отображает системные DLL Win32 (KERNEL32.DLL, USER32.DLL и т. д.) в это адресное пространство. Данные файлы используются совместно, то есть несколько процессов могут обращаться к единственной копии такого файла в физической памяти.

Область D доступна для программ пользовательского режима (однако размещать их здесь не рекомендуется).

Область Е

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

Она также доступна для программ пользовательского режима.

Распределение виртуальной памяти

Каждая страница виртуального адресного пространства может находиться в одном из трех состояний:

· Reserved (зарезервирована) — страница зарезервирована для использования;

· Committed (передана) — для данной виртуальной страницы выделена физическая память в файле подкачки или в файле, отображаемом в память;

· Free (свободна) — данная страница не зарезервирована и не передана, и поэтому в данный момент она недоступна для процесса.

Виртуальная память может быть зарезервирована или передана с помощью вызова API-функции VirtualAlloc:

LPVOID VirtualAlloc(

LPVOID IpAddress, //Адрес резервируемой или выделяемой области.

DWORD dwSise, //Объем области.

DWORD flAllocationType, // Тип распределения.

DWORD flProtect // Тип защиты от доступа.

);

Параметр flAllocationType может принимать значения следующих констант (помимо других);

· MEM_RESERVE — параметр, резервирующий область виртуального адресного пространства процесса без выделения физической памяти. Тем не менее, память может быть выделена при следующем вызове этой же функции;

· МЕМ_СОММIТ — параметр, выделяющий физическую память в оперативной памяти или в файле подкачки на диске для заданного зарезервированною набора страниц.

Эти две константы могут объединяться для того, чтобы зарезервировать и выделить память одной операцией.

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

Windows тоже использует этот подход, когда выделяет память под стек каждого вновь создаваемого потока. Система резервирует 1 Мб виртуальной памяти под стек каждого потока, но выделяет первоначально только две страницы (8 Кб).

Защита памяти

Параметр flProtect функции virtualAlloc используется для задания типа защиты от доступа, соответствующего вновь выделенной (committed) виртуальной памяти (это не относится к резервируемой памяти). Существуют следующие методы защиты:

· PAGE_READONLY присваивает доступ «только для чтения» выделенной виртуальной памяти;

· PAGE_READWRITE назначает доступ «чтение-запись» выделенной виртуальной памяти;

· PAGE_WRITECOPY устанавливает доступ «запись копированием» (сору-оnwrite) выделенной виртуальной памяти.

· PAGE_EXECUTE разрешает доступ «выполнение» выделенной виртуальной памяти. Тем не менее, любая попытка чтения — записи этой памяти приведет к нарушению доступа;

· PAGE_EXECUTE_READ назначает доступ «выполнение» и «чтение»;

· PAGE_EXECUTE_READWRITE разрешает доступ «выполнение», «чтение» и «запись»;

· PAGE_EXECUTE_WRITECOPY присваивает доступ «выполнение», «чтение» и «запись копированием»;

· PAGE_NOACCESS запрещает все виды доступа к выделенной виртуальной памяти.

Любые из этих значений, за исключением PAGE_NOACCESS, могут комбинироваться при помощи логического оператора OR со следующими двумя флагами:

· PAGE_GUARD определяет помеченные страницы как защищенные (guard page). При любой попытке обращения к защищенной странице система возбуждает исключительную ситуацию STATUS_GUARD_PAGE и снимает с данной страницы статус защищенной. Таким образом, защищенные страницы предупреждают только о первом обращении к ним;

· PAGE_NOCACHES запрещает кэширование выделенной памяти.

Следует объяснить, что такое доступ «запись копированием». Допустим, некоторая страница физической памяти совместно используется двумя процессами. Если она помечена как «только для чтения», то два процесса без проблем могу совместно пользоваться этой страницей. Однако возможны ситуации, когда каждому процессу требуется разрешить запись в эту память, но без воздействия и другой процесс. После установки защиты «запись копированием» при попытке записи в совместно используемую страницу система создаст ее копию специально для процесса, которому нужно осуществить запись. Таким образом, данная страница перестает быть совместно используемой, а представление ее данных в других процессах остается неизменным.

Необходимо отметить, что атрибуты защиты страницы могут быть изменены с помощью API-функции Virtual Protect.

Гранулярность при распределении памяти

Если параметр IpAddress не является кратным 64 Кб, то система округляет указанный адрес в меньшую сторону до ближайшего числа, кратного 64 Кб. Windows всегда выравнивает начальный адрес виртуальной памяти на границу гранулярности распределения (allocation granularily), которая является числом кратным 64 Кб (при использовании процессоров Intel). Другими словами, начальный адрес любого блока зарезервированной памяти представляет собой число кратное 64 Кб.

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

Дескриптор виртуальных адресов

Система отслеживает, какие из виртуальных страниц являются зарезервированными, при помощи структуры, называемой дескриптором виртуальных адресов (Virtual Address Descriptor — VAD). Другого способа определения не существует.

Пример использования функции GlobalMemoryStatus

API-функция GlobalMemoryStatus, записывающаяся таким образом:

В Delphi:

Procedure GlobalMemoryStatus(var lpBuffer: TMemoryStatus); stdcall;

Procedure GlobalMemoryStatus; external kernel32 name ‘GlobalMemoryStatus’;

Выводит множество данных, имеющих отношение к памяти, в составе следующей структуры:

Struct_MEMORYSTATUS {

DWORD dwLength; // Размер структуры MEMORYSTATUS.

DWORD dwMernoryLoad; // Процент используемой памяти.

DWORD dwTotalPhys; // Количество байтов физической памяти.

DWORD dwАvailPhys; // Количество свободных байтов физической памяти.

DWORD dwTotalPageFile; // Размер в байтах файла подкачки.

DWORD dwAvailPageFile; // Количество свободных байтов файла подкачки.

DWORD dwTotalVirtual; // Количество байтов адресного пространства,

// доступного пользователю.

DWORD dwAvailvirtual; // Количество свободных байтов памяти,

// доступных пользователю.

End Type

В Delphi:

_MEMORYSTATUS = record

dwLength: DWORD;

dwMemoryLoad: DWORD;

dwTotalPhys: DWORD;

dwAvailPhys: DWORD;

dwTotalPageFile: DWORD;

dwAvailPageFile: DWORD;

dwTotalVirtual: DWORD;

dwAvailVirtual: DWORD;

end;

Управление виртуальной памятью

Рассмотрим, как диспетчер виртуальной памяти Windows преобразует адреса виртуальной памяти и физические.

Преобразование виртуальных адресов в физические: попадание

На рисунке показан процесс преобразования при отображении виртуальных адресов в физические. Он называется попаданием в (физическую) страницу (Page Hit).

Все виртуальные адреса делятся на три части. Самая левая часть (биты 22-31) содержит индекс каталога страниц процесса. Windows поддерживает отдельный каталог страниц для каждого процесса. Его адрес хранится в одном из регистров центрального процессора, который называется CR3. (В операцию переключения задач входит переведение CR3 в состояние, когда он указывает на каталог страниц процесса, на который осуществляя переключение.) Каталог страниц одержит 1024 четырехбайтовых элемента.

Windows поддерживает для каждого процесса совокупность таблиц страниц (page table). Каждый элемент каталога страниц содержит уникальный номер. Поэтому Windows поддерживает до 1024 таблиц страниц. ( В действительности таблицы страниц создаются только при попытке обращения к данным или коду конкретному виртуальному адресу, а не когда выделяется виртуальная память).

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

Третья, и последняя, часть виртуального адреса (биты 0-11) представляет собой смещение в данном страничном блоке. Сочетание номера страничного блока и смещения дают в совокупности адрес физической памяти.

Так как каждая таблица страниц состоит из 1024 элементов и количество таблиц равно 1024, общее количество страничных блоков, которое можно определить, таким образом, будет 1024 х 1024 = 210 х 210 = 220. Так как каждый страничный блок имеет объем 4 Кб = 4 х 210 байт, то теоретический предел физического адресного пространства будет 4 х 230 = 4 Гб.

У этой довольно сложной схемы преобразования есть несколько важных преимуществ. Одно из них — очень небольшой объем страничных блоков, которые легко могут быть размещены в памяти. Гораздо легче найти непрерывный блок памяти размером 4 Кб, чем, скажем, 64 Кб.

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

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

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

Каталог и таблицы системных страниц

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

Совместно используемые страницы

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

Рабочие наборы

Каждая страница виртуального адресного пространства процесса объемом 4 Гб существует в одном из трех состояний — свободном (free), зарезервированном (reserved) или переданном (committed). Теперь можно также сказать, что каждая переданная страница (Committed Page) является или действительной, или недействительной. Совокупность действительных страниц, то есть спроецированных на физическую память, называют рабочим наборам (Working Set) процесса. Рабочий набор постоянно меняется по мере того, как страницы подкачиваются в память или выполняется обратное действие.

Системный рабочий набор (System Working Set) характеризует виртуальные страницы системной памяти, которые в данный момент отображены на физическую память.

Размер рабочего набора процесса ограничен теми установками, которые определяет Windows в зависимости от объема физической памяти. Эти значения приведены в следующей таблице.

Эти пределы могут быть изменены с помощью API-функции

SetProcessWorkingSetSize:

BOOL SetProcessWorkingSetSize(

HANDLE hProcess, // Открытый дескриптор интересующего процесса.

DWORD dwMinimumWorkingSetSize,

// Задает мин. размер рабочего набора в байтах.

DWORD dwMaximumWorkingSetSize

// Задает максимальный размер рабочего набора в байтах.

);

Присвоение каждому из двух параметров размера значения -1 приведет к тому, что функция сожмет размер рабочего набора до 0 и тем самым временно удалит данный процесс из физической памяти.

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

Пределы размера системного рабочего набора приведены в следующей таблице.

База данных страничных блоков

Windows фиксирует coстояние каждой физической страницы памяти в структуре данных, называемой базой данных страничных блоков (Page Frame Database). Каждая физическая страница может находиться в одном из восьми различных стояний:

· активная, или действительная (Active, Valid). Страница в текущий момент отображается на виртуальную память, входя, таким образом, в рабочий набор страниц;

· переходная (Transition). Страница в процессе перехода к активному состоянию;

· резервная (Standby). Страница только что вышла из состояния «активная», но осталась неизменной;

· измененная (Modified). Страница вышла из состояния «активная». Ее содержание, пока она находилась в указанном состоянии, было изменено, но еще не записано на диск;

· измененная незаписанная (Modified No Write). Страница находится в состоянии «измененная», но особо помечена как страница, содержимое которой не сброшено на диск. Используется драйверами файловой системы Windows;

· свободная (Free). Страница свободна, но содержит произвольные записи и, следовательно, не может использоваться процессом;

· обнуленная (Zeroed). Страница свободна и инициализирована нулями потоком нулевой страницы. Может быть выделена процессу;

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

Кучи памяти в 32-разрядной Windows

При создании процесса Windows назначает ему кучу по умолчанию (Default Heap), то есть изначально резервирует область виртуальной памяти объемом 1 Мб. Тем не менее, при необходимости система будет регулировать размер кучи, которая используется самой Windows для различных целей.

API-функция GetProcessHeap используется для получения дескриптора кучи. При помощи функции HeapCreatЕ, возвращающей дескриптор кучи, программист может создавать дополнительные кучи.

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

16-разрядная Windows поддерживает и глобальную, и локальную кучи. Соответственно в данной системе реализованы функции GlobalAlloc и LocalAlloc. Они выполняются, но не очень эффективны, поэтому следует избегать их применения в Win32. Однако их все-таки приходится использовать для некоторых целей, таких как создание окна просмотра буфера обмена.

Функции работы с кучей

Для работы с кучами используются следующие функции:

· GetProcessHeap возвращает дескриптор кучи процесса по умолчанию;

· GetProcessHeaps возвращает список дескрипторов всех куч, используемых в данный момент процессом;

· HeapAlloc выделяет блок памяти из заданной кучи;

· HeapCompact дефрагментирует кучу, объединяя свободные блоки. Может также освобождать неиспользуемые страницы памяти кучи;

· HeapCreatE создает новую кучу в адресном пространстве процесса;

· HeapDestroy удаляет заданную кучу;

· HeapFree Освобождает предварительно выделенные блоки памяти кучи;

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

· HeapReAlloc перераспределяет блоки памяти кучи. Используется для изменения размера блока;

· Heapsize возвращает размер выделенного блока памяти кучи;

· HeapUnlock разблокирует кучу, которая до этого была заблокирована функцией HeapLock;

· HeapValidate проверяет пригодность кучи (или отдельного ее блока), если имеются ли какие-либо повреждения;

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

Отображения виртуальной памяти

Функция Win32 API VirtualQuery может использоваться для получения информации о состоянии адресов виртуальной памяти. Синтаксис ее таков:

DWORD VirtualQuery(

LPCVOID IpAddress, // Адрес области.

PMEMORY_BASICONFORMATION IpBuffer, // Адрес информационного буфера

DWORD DwLength // Размер буфера

);

Используется также функция VirtualQueryEx, расширенная версия VirtualQuery, которая позволяет получать информацию о внешних виртуальных адресных пространствах:

DWORD VirtualQueryEx(

HANDLE hProcess // Дескриптор процесса

LPCVOID IpAddress, // Адрес области

MEMORY_BASIC_INFORMATION IpBuffer, // Адрес информационного буфера

DWORD DwLength // Размер буфера

);

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

Struct MEMORY_BASlC_INFORMATION {

PVOID BaseAdciress; // Базовый адрес области

PVOID AllocationBase; // Базовый адрес выделенной области

DWORD AllocationProtect; // Первоначальная защита от доступа

DWORD RegionSize; // Размер области в байтах

DWORD State; // Передана зарезервирована, свободна

DWORD Protect; // Текущая защита от доступа

DWORD Type; // Тип страниц

}

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

Функция VirtualQueryEx всегда заполняет следующие члены структуры

MEMORY_BASIC_INFORMATION:

· BaseAddress, которая возвращает базовый адрес заданной страницы;

· RegionSize, представляющая собой количество байтов от начала заданной страницы до вершины заданной области.

Если страница, содержащая адрес IpAddress, свободна (не зарезервирована и не передана), член структуры Stаte содержит символьную константу MEM_FREE. Остальные члены (кроме BaseAddress и RegionSize) не имеют значения.

Если страница, содержащая адрес IpAddress, не свободна, функция определяет выделенную область (allocation region), то есть область виртуальной памяти, которая включает заданную страницу и была, первоначально выделена с помощью вызова функции VirtualAlloc.

Начиная с базового адреса заданной страницы, функция последовательно просматривает все страницы выделенной области, проверяя, совпадают ли их типы выделения (Allocation Type) и защиты (Protection Type) с аналогичными типами заданной страницы. Совокупность всех совпадающих упорядоченных страниц представляет собой заданную область. К ней относятся значения структуры MEMORY_BASIC_INFORMATION. Cтраница считается совпадающей с заданной страницей, если она удовлетворяет двум следующим условиям:

· страница имеет тот же тип выделения, что и первоначальная страница, в соответствии со следующими значениями флага: MEM_COMMIT, MEM_RESERVE, MEM_FREE, MEM_PRIVATE, MEM_MAPPED Или MEM_IMAGE;

· страница имеет тот же тип зашиты, что и первоначальная страница, в соответствии со следующими значениями флага: PAGE_READONLY, PAGE_READWRITE, PAGE_NOACCESS, PAGE_WRITECOPY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_EXECUTE_WRITECOPY, PAGE_GUARD Или PAGE_NOCACHE.

Рассмотрим остальные члены структуры MEMORY_BASIC_INFORMATION:

· AllocationBase — базовый адрес выделенной области;

· AllocationProtect — первоначальный тип защиты выделенной области;

· State — одно из трех значений: MEM_FREE, MEM_RESERVE или МЕМ_СОММIТ. Относится к заданной области;

· Protect — текущий тип защиты заданной области;

· Туре — одно из трех значений: MEM_IMAGE, MEM_MAPPED Или MEM_PRIVATE. Относится к заданной области. Эти константы имеют следующий смысл: MEM_IMAGE указывает, что область отображена на файл образа задачи (Image File), то есть на загрузочный; MEM_MAPPED указывает, что область отображена на не загрузочный отображаемый в память файл (например, файл данных); MEM__PRIVATE указывает, что область используется одним процессом, а не совместно.

СОДЕРЖАНИЕ ОТЧЕТА

8. Наименование лабораторной работы, ее цель.

9. Разработанное программное обеспечение для приложения, которое:

· выдает информацию, получаемую при использовании API GlobalMemoryStatus. При выводе информации использовать диаграммы.

· Составляет карту виртуальной памяти для любого процесса.

10. Примеры разработанных приложений (результаты и тексты программ).