Функции для работы с виртуальной памятью

Обновлено: 05.07.2024

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

– выделен (committed) – блоку адресов назначена физическая память либо часть файла подкачки;

– зарезервирован (reserved) – блок адресов помечен как занятый, но физическая память для него не распределена;

– свободен (free) – блок адресов не выделен и не зарезервирован.

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

Функция VirtualAlloc выделяет (резервирует) регион памяти и возвращает его адрес или NULL в случае неудачи:

LPVOID lpAddress, //адрес региона

DWORD dwSize, //размер региона

DWORD flAllocationType, //тип выделения

DWORD flProtect //права (защита) доступа

lpAddress – адрес, по которому надо зарезервировать или выделить память. Этот параметр может быть NULL, тогда система самостоятельно выбирает место в адресном пространстве процесса.

dwSize – размер выделяемого региона.

flAllocationType – тип распределения памяти: MEM_RESERVE – резервирование блока адресов без выделения памяти; MEM_COMMIT – отображение ранее зарезервированного блока адресов на физическую память или файл подкачки, при этом происходит реальное выделение памяти; может объединяться с MEM_RESERVE для одновременного резервирования и выделения; MEM_TOP_DOWN – выделять память по наибольшему возможному адресу; имеет смысл только при lpAddress == NULL, в Windows 95 игнорируется.

flProtect – тип защиты доступа выделяемого региона: PAGE_READONLY – допускается только чтение; PAGE_READWRITE – допускается чтение и запись; PAGE_EXECUTE – допускается только исполнение; PAGE_EXECUTE_READ – допускается исполнение и чтение; PAGE_EXECUTE_READWRITE – допускается исполнение чтение и запись; PAGE_GUARD – дополнительный флаг защиты, который комбинируется с другими флагами; при первом обращении к странице этот флаг сбрасывается и возникает исключение STATUS_GUARD_PAGE, этот флаг используется для контроля размеров стека с возможностью его динамического расширения; PAGE_NOCACHE – запрет кэширование страниц, может быть полезен при разработке драйверов устройств (например, данные в видеобуфер должны переписываться сразу, без кэширования).

Функция VirtualFree освобождает ранее выделенный регион, в случае успеха возвращает TRUE:

LPVOID lpAddress, //адрес региона

DWORD dwSize, //размер региона

DWORD dwFreeType //"тип освобождения"

lpAddress – адрес региона, который надо освободить.

dwSize – размер освобождаемого региона;

dwFreeType – тип освобождения: MEM_DECOMMIT – освободить выделенную память; MEM_RELEASE – освободить зарезервированный регион, при этом параметр dwSize должен быть равен нулю.

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

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

Функции VirtualQuery и VirtualQueryEx позволяют определить статус указанного региона адресов.

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

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

Размер виртуальной памяти теоретически ограничивается разрядностью операционной системы. На практике в конкретной реализации операционной системы устанавливаются ограничения ниже теоретического предела. Например, для 32-разрядных систем ( x86 ), которые используют для адресации 32 разрядные регистры и переменные, теоретический максимум составляет 4 ГБ (2 32 байт = 4 294 967 296 байт = 4 ГБ). Однако для процессов доступна только половина этой памяти – 2 ГБ, другая половина отдается системным компонентам. В 64 разрядных системах (x64) теоретический предел равен 16 экзабайт (2 64 байт = 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. . Отметим, что каждый процесс имеет свое собственное пользовательское ВАП, а системное ВАП для всех процессов одно и то же.


Рис. 11.1. Реализация виртуальной памяти в 32-разрядных Windows

Виртуальная память делится на блоки одинакового размера – виртуальные страницы. В 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 МБ.


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

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

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

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

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

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

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

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

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

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

Для хранения информации о зарезервированных страницах памяти используются дескрипторы виртуальных адресов ( Virtual Address Descriptors, VAD ). Каждый дескриптор содержит данные об одной зарезервированной области памяти и описывается структурой MMVAD ( файл base\ntos\mm\mi.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.

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

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

DwSize - размер памяти. Но эта величина очень специфичная. Память выделяется блоками по 4096 байт и соответственно указанный размер будет округляться до этого числа. Выделяете память например 10 байт, а получите 4096, а если выделяете например 5000, то будет выделено памяти в 8192 байта. Округление естественно идет в сторону увеличения.

  • MEM_COMMIT - Выполняется выделение страниц памяти для непосредственной работы с ними. Выделенные страницы заполняются нулями.
  • MEM_TOP_DOWN - Память выделяется в области верхних адресов адресного пространства приложения.

Как видите мы можем получить память, зарезервировать.

  • PAGE_READWRITE - Чтение и запись.
  • PAGE_READONLY - Только чтение.
  • PAGE_EXECUTE - Только исполнение программного кода.
  • PAGE_EXECUTE_READ - Исполнение и чтение.
  • PAGE_EXECUTE_READWRITE - Исполнение, чтение и запись.
  • PAGE_NOACCESS - Запрещен любой вид доступа.
  • PAGE_GUARD - Сигнализация доступа к странице. Это значение можно использовать вместе с любыми другими, кроме PAGE_NOACCESS.
  • PAGE_NOCACHE - Отмена кэширования для страницы памяти. Используется драйверами устройств. Это значение можно использовать вместе с любыми другими, кроме PAGE_NOACCESS.

При успешном выполнении функция вернет указатель на выделенную память, иначе NULL.

Функция VirtualFree освобождает выделенную память.

dwSize - размер, если мы будем использовать тип освобождения, как MEM_RELEASE, то размер должен быть установлен в 0.

Работа приложений с виртуальной памятью Архитектура интерфейсов управления памятью Файлы, отображаемые в память Кучи Заключение Литература Virtual memory API Работа приложений с виртуальной памятью Архитектура интерфейсов управления памятью Составной частью ядра операционной системы является VMM.

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

Архитектура интерфейсов управления памятью

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

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

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

Memory Mapped File API - набор функций использования файлов, отображаемых в память. Этот новый с точки зрения классического устройства ОС механизм предоставляется Win32 API для работы с файлами и взаимодействия процессов между собой;

Heap Memory API - набор функций для управления динамически распределяемыми областями памяти (кучами). Интерфейс построен с помощью Virtual Memory API;

Local, Global Memory API - программный интерфейс для работы с памятью, совместимый с 16-разрядной Windows (лучше его не использовать);

CRT Memory API - функции стандартной библиотеки времени исполнения языка Cи (C Run Time library).

Два последних набора функций в данной статье не рассматриваются.

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

Файлы, отображаемые в память, - это один из самых замечательных сервисов, которые Win32 предоставляет программисту. Его существование стирает для программиста грань между оперативной и дисковой памятью. Действительно, с точки зрения классической теории кэш, оперативная память и дисковое пространство - это три вида памяти, отличающиеся скоростью доступа и размером. Но если заботу о перемещении данных между кэшем и оперативной памятью берут на себя процессор и операционная система, то перемещение данных между оперативной памятью и диском обычно выполняет прикладной процесс с использованием функций read() и write(). Win32 действует иначе: операционная система берет на себя заботу о перемещении страниц адресного пространства процесса, находящихся в файле подкачки, причем в качестве файла подкачки может быть использован любой файл. Иначе говоря, страницы виртуальной памяти любого процесса могут быть помечены как выгруженные, а в качестве места, куда они выгружены, может быть указан файл. Теперь при обращении к такой странице VMM произведет ее загрузку, используя стандартный механизм свопинга. Это позволяет работать с произвольным файлом как с регионом памяти. Данный механизм имеет в Win32 три применения:

  • для запуска исполняемых файлов (EXE) и динамически связываемых библиотек (DLL);
  • для работы с файлами;
  • для совместного использования одной области данных двумя процессами.

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

Рассмотрим механизм запуска программы на выполнение более подробно. При исполнении функции CreateProcess система обращается к VMM для выполнения следующих действий:

  1. Создать адресное пространство процесса.
  2. Зарезервировать в адресном пространстве процесса регион размером, достаточным для размещения исполняемого файла. Начальный адрес региона берется из заголовка EXE-модуля. Обычно он равен 0x00400000, но может быть изменен при построении файла заданием параметра /BASE компоновщика.
  3. Отобразить исполняемый файл на зарезервированное адресное пространство. Тем самым VMM распределяет физические страницы не из файла подкачки, а непосредственно из EXE-модуля.
  4. Отобразить в адресное пространство процесса необходимые ему динамически связываемые библиотеки. Информация о необходимых библиотеках читается из заголовка EXE-модуля. Желательное расположение региона адресов описано внутри отображаемых библиотек. Visual C++, например, по умолчанию устанавливает для своей библиотеки адрес 0x10000000. Этот адрес может тоже изменяться параметром /BASE компоновщика. Если при загрузке выясняется, что данный регион занят, то система попытается переместить библиотеку в другой регион адресов, согласуя это действие с настроечной информацией, содержащейся в DLL-модуле. Однако эта операция снижает эффективность системы, и кроме того, если при компоновке библиотеки настроечная информация удалена (параметр/FIXED), то загрузка становится вообще невозможной. Интересно, что все стандартные библиотеки Windows имеют фиксированный адрес загрузки, и каждая свой собственный.

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

Мы уже обсуждали выше, что Win32, используя технологию lazy evaluation, откладывает решение этой проблемы на максимально возможный срок. Все страницы адресного пространства процесса, на которые отображен EXE-файл, получают атрибут защиты PAGE_WRITECOPY. При попытке записи в такую страницу возникает исключение нарушения защиты, и VMM копирует страницу для обратившегося процесса. В дальнейшем эта страница всегда будет выгружаться в файл подкачки. После копирования происходит повторный старт команды, вызвавшей исключение.

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

Для открепления файла от адресного пространства процесса используется функция UnmapViewOfFile(), а для уничтожения объектов "файл" и "отображаемый файл" - функция CloseHandle.

Общая методика работы с отображаемыми файлами такова:

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

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

Кучи (heaps) - это динамически распределяемые области данных. При порождении процесса ему предоставляется куча размером 1 Мбайт по умолчанию. Ее размер может изменяться параметром /HEAP при построении исполняемого модуля. Функции библиотеки времени исполнения компилятора (malloc(), free() и т. д.) используют возможности куч.

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

HANDLE GetProcessHeap( VOID ) - для получения дескриптора кучи по умолчанию;

LPVOID HeapAlloc( HANDLE hHeap, DWORD dwFlags, DWORD dwSize ) - выделяющая блок памяти заданного размера из кучи и возвращающая указатель на этот блок;

LPVOID HeapReAlloc( HANDLE hHeap, DWORD dwFlags, LPVOID lpOldBlock, DWORD dwSize) - изменяющая размер выделенного блока памяти, при этом она может перемещать блок, если нет достаточного места для простого расширения;

BOOL HeapFree(HANDLE hHeap, DWORD dwFlags, LPVOID lpMem ) - освобождает выделенный блок памяти кучи.

Иногда имеет смысл пользоваться дополнительными кучами, создание которых производится функцией HANDLE HeapCreate(DWORD dwFlags, DWORD dwInitialSize, DWORD dwMaximumSize) . Целесообразно использовать дополнительные кучи для защиты друг от друга различных структур данных, для повышения эффективности управления памятью и др. В системах со страничной организацией отсутствует проблема фрагментации физической памяти, однако существует проблема фрагментации адресного пространства. В 4-Гбайт адресном пространстве эта проблема не актуальна, но она имеет значение в куче размером 1 Мбайт. Если элементы какой-либо структуры имеют один размер, а элементы другой структуры - другой, то полезно размещать эти структуры в разных кучах. Кроме того, дополнительные кучи могут быть применены и для уменьшения рабочего множества процесса. В соответствии с принципом локальности работа с разными структурами чаще всего происходит не одновременно. Границы элементов разных структур не выравниваются на границу страницы, поэтому обращение к элементам одной структуры вызывает подкачку всей страницы, а значит, и элементов другой структуры. Это увеличивает рабочее множество процесса.

Заключение

Автор этих строк читает студентам лекции по курсу "Системное программное обеспечение". Саму дисциплину назвать новой никак нельзя. Теория организации вычислительного процесса сложилась уже к началу 70-х. Существовавшие в то время операционные системы давали массу примеров, позволяющих скрасить сухое академическое изложение. И сегодня по-прежнему излюбленной операционной системой для университетов является Unix, на которой воспитано не одно поколение студентов (в том числе и ваш покорный слуга). Никоим образом не умаляя достоинств Unix, можно с уверенностью утверждать, что Windows NT является ничуть не менее "классической" операционной системой в том смысле, что она доставляет примеры удачной реализации во всех разделах теории. Это не удивительно, ведь инженеры, создававшие Windows NT, были очень хорошо знакомы с такими системами, как Unix и Open VMS. При создании Windows NT было найдено много интереснейших технических решений, ряд из которых рассмотрен в данной статье, и название NT - New Technologies - можно считать вполне оправданным.

Андрей Федоров
- генеральный директор Digital Design Microsoft.

Литература

  1. Дейтел Г. Введение в операционные системы. М.: Мир.
  2. Донован Дж. Системное программирование. М.: Мир, 1975.
  3. Changes and Additions to the Alpha Architecture Definition. September 18, 1996.
  4. Randy Kath. The Virtual-Memory Manager in Windows NT. MSDN. Created: December 21, 1992.
  5. Pentium Pro Family Developer's Manual. Volume 3: Operating System Writer's Guide.
  6. How Windows NT Provides 4 Gigabytes of Memory. MSDN Knowledge Base. Article ID: Q99707. Creation Date: 06-JUN-1993. Revision Date: 17-JAN-1995.
  7. Рихтер Д. Windows для профессионалов. М.: изд. отд. "Русская редакция" ТОО Channel Trading Ltd., 1995.
  8. Working Set Size, Nonpaged Pool, and VirtualLock(). MSDN Knowledge Base. Article ID: Q108449. Creation Date: 12-DEC-1993. Revision Date: 02-NOV-1995.

Virtual memory API

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

  • выделен (committed) - блоку адресов назначена физическая память либо часть файла подкачки;
  • зарезервирован (reserved) - блок адресов помечен как занятый, но физическая память не распределена;
  • свободен (free) - блок адресов не выделен и не зарезервирован.

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

Для резервирования региона памяти в адресном пространстве процесса или ее выделения используется функция VirtualAlloc(), а для освобождения - функция VirtualFree():

Эта функция возвращает адрес выделенного региона, а в случае неудачи возвращает NULL. Параметры функции:

lpAddress - адрес, по которому надо зарезервировать или выделить память. Если этот параметр равен NULL, то система самостоятельно выбирает место в адресном пространстве процесса;

dwSize - размер выделяемого региона;

flAllocationType - тип распределения памяти;

flProtect - тип защиты доступа выделяемого региона:

PAGE_READONLY - допускается только чтение;

PAGE_READWRITE - допускается чтение и запись;

PAGE_EXECUTE - допускается только выполнение;

PAGE_EXECUTE_READ - допускается исполнение и чтение;

PAGE_EXECUTE_READWRITE - допускается выполнение, чтение и запись;

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

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

Возвращает TRUE в случае успеха и FALSE в случае неудачи. Параметры:

lpAddress - адрес региона, который надо освободить;

dwSize - размер освобождаемого региона;

dwFreeType - тип освобождения.

Параметр flAllocationType может принимать следующие значения:

MEM_RESERVE - резервирует блок адресов без выделения памяти;

MEM_COMMIT - отображает ранее зарезервированный блок адресов на физическую память или файл подкачки, выделяя при этом память. Может комбинироваться с флагом MEM_RESERVE для одновременного резервирования и выделения;

MEM_TOP_DOWN - выделяет память по наибольшему возможному адресу. Имеет смысл только при lpAddress = NULL. В Windows 95 игнорируется.

MEM_DECOMMIT - освободить выделенную память;

MEM_RELEASE - освободить зарезервированный регион. При использовании этого флага параметр dwSize должен быть равен нулю.

Выделенные страницы можно заблокировать в памяти, т. е. запретить их вытеснение в файл подкачки. Такие страницы остаются в составе рабочего множества процесса до того момента, как будут разблокированы. Для этих целей служит пара функций VirtualLock() и VirtualUnlock(). Процессу не разрешается блокировать более 30 страниц. Для настройки рабочего множества процесса может использоваться и функция SetProcessWorkingSetSize() [8]. Формально она не входит в состав Virtual Memory API, но тесно с ним связана. Например, использование этой функции снимет барьер 30 страниц для функции VirtualLock().

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

Функции VirtualQuery() и VirtualQueryEx() позволяют определить статус указанного региона адресов.

Читайте также: