Внешние менеджеры памяти

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

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

Третьим является порт имени (name port), который используется как разновидность имени, с помощью которого идентифицируется объект. Например, нить может передать ядру виртуальный адрес и спросить, к какой области он относится. Ответом будет указатель на порт имени. Если адреса относятся к одной и той же области, то они будут идентифицироваться одним и тем же портом имени.

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

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

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

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

Ядро отображает страницу в адресное пространство вызвавшего обращение процесса. Теперь нить может быть разблокирована. Этот процесс повторяется до тех пор, пока все нужные страницы не загрузятся.

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

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

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

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

В таблице 6.4 приведен список типов сообщений, которые ядро посылает менеджеру памяти.

Таблица 6.4.  Некоторые типы сообщений, посылаемых ядром менеджеру сообщений

Вызов	Описание
Init	Инициализировать новый отображенный в память объект
Data_request	Передать ядру определенную страницу для обработки страничного отказа
Data_write	Взять страницу из памяти и переписать ее
Data_unlock	Разблокирует страницу, так что ядро может ее использовать
Lock_completed	Завершено выполнение предшествующий запрос Lock_request
Terminate	Информирование о том, что данный объект больше не используется

Когда объект отображается в память с использованием вызова Map, то ядро посылает сообщение Initсоответствующему менеджеру памяти, чтобы позволить ему инициализировать себя. Это сообщение определяет порты, которые должны будут использоваться позже в диалоге с объектом. Запросы от ядра на получение страницы и поставку страницы осуществляются с помощью вызовов Data_request и Data_writeсоответственно. Эти сообщения управляют трафиком страниц в обоих направлениях, и поэтому являются наиболее важными вызовами.

Сообщение Data_unlock представляет собой запрос от ядра менеджеру памяти на разблокирование заблокированной страницы, так что ядро может использовать ее для другого процесса. СообщениеLock_completed оповещает о завершении последовательности Lock_request, и будет рассмотрен ниже. Наконец, сообщение Terminate сообщает менеджеру памяти, что объект, имя которого указано в вызове, больше не используется и может быть удален из памяти. Существуют вызовы, определенные для менеджера памяти "по умолчанию".

Сообщения, перечисленные в таблице 6.5, передаются от внешнего менеджера памяти ядру.

Таблица 6.5.  Сообщения, посылаемые менеджером памяти ядру

Вызов	Описание
Set_attributes	Ответ на вызов Init
Data_provided	Ответ на вызов Data_request - здесь: запрошенная страница доставлена
Data_unavailable	Ответ на вызов - страницы нет в наличии
Lock_request	Запрашивает ядро для выполнения очистки, вытеснения или блокировки страниц
Destroy	Разрушить объект, который больше не нужен

Первое сообщение, Set_attributes, является ответом на сообщение Init. Оно сообщает ядру, что менеджер готов обрабатывать вновь отображенный объект. Ответ также содержит биты режима для объекта и говорит ядру, следует или нет кэшировать объект, даже если ни один процесс в какой-либо момент времени не отображает его. Следующие два сообщения являются ответами на сообщение Data_request. Это сообщение запрашивает страницу у менеджера памяти. Ответ менеджера зависит от того, может он предоставить страницу или нет. Первое сообщение говорит о том, что может, второе - о том, что нет.

Сообщение Lock_request позволяет менеджеру памяти попросить ядро очистить некоторые страницы, то есть послать ему эти страницы, чтобы они могли быть записаны на диск. Это сообщение может быть использовано также и для того, чтобы изменить режим защиты страниц (чтение, запись, выполнение). Наконец, сообщение Destroy служит для уведомления ядра о том, что некоторый объект больше не нужен.

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