Виртуальная память в Microsoft Windows реферат по информатике , Сочинения из Информатика

Скачай Виртуальная память в Microsoft Windows реферат по информатике и еще Сочинения в формате PDF Информатика только на Docsity! Виртуальная память в Microsoft Windows Здесь мы рассмотрим архитектуру памяти, применяемую в Microsoft Windows. Виртуальное адресное пространство процесса Каждому процессу выделяется собственное виртуальное адресное пространство. Для 32-разрядных процессов его размер составляет 4 Гб. Соответственно 32-битный указатель может быть любым числом от 0x00000000 до 0xFFFFFFFF. Всего, таким образом, указатель может принимать 4 294 967 296 значений, что как раз и перекрывает четырехгигабайтовый диапазон. Для 64-разрядных процессов размер адресного пространства равен 16 экзабайтам, поскольку 64-битный указатель может быть любым числом от 0x00000000 00000000 до 0xFFFFFFFF FFFFFFFF и принимать 18 446 744 073 709 551 616 значений, охватывая диапазон в 16 экзабайтов.Поскольку каждому процессу отводится закрытое адресное пространство, то, когда в процессе выполняется какой-нибудь поток, он получает доступ только к той памяти, которая принадлежит его процессу. Память, отведенная другим процессам, скрыта от этого потока и недоступна ему. В Windows 2000 память, принадлежащая собственно операционной системе, тоже скрыта от любого выполняемого потока. Иными словами, ни один поток не может случайно повредить ее данные.В Windows 2000, ни один поток не может получить доступ к памяти чужого процесса. Итак, адресное пространство процесса закрыто. Отсюда вытекает, что процесс А в своем адресном пространстве может хранить какую-то структуру данных по адресу 0x12345678, и одновременно у процесса В по тому же адресу —но уже в его адресном пространстве — может находиться совершенно иная структура данных. Обращаясь к памяти по адресу 0x12345678, потоки, выполняемые в процессе А, получают доступ к структуре данных процесса А, Но, когда по тому же адресу обращаются потоки, выполняемые в процессе В, они получают доступ к структуре данных процесса В. Иначе говоря, потоки процесса А не могут обратиться к структуре данных в адресном пространстве процесса В, и наоборот Как адресное пространство разбивается на разделы Виртуальное адресное пространство каждого процесса разбивается на разделы. Их размер и назначение в какой-то мере зависят от конкретного ядра Windows (таблица 13-1) Раздел -разрядная Windows 2000 (на х86 и Alpha) -разрядная Windows 2000 (на х86 с ключом /3GB) -разрядная Windows 2000 (на Alpha и А-64) Windows 98 Для выявления x00000000 x00000000 x00000000 00000000 x00000000 нулевых указателей x0000FFFF x0000FFFF x00000000 0000FFFF x00000FFF Для совместимости с программами DOS и 16- разрядной Windows Hет Нет Нет x00001000 0x003FFFFF Для кода и данных 0x00010000 x00010000 x00000000 00010000 x00400000 пользовательског о режима x7FFEFFFF xBFFFFFFF x000003FF FFFEFFFF x7FFFFFFF Закрытый, x7FFF0000 xBFFF0000 x000003FF FFFF0000 Нет размером 64 Кб x7FFFFFFF xBFFFFFFF x000003FF FFFFFFFF Для общих MMF (файлов, проецируемых в память) Нет Нет Нет x80000000 0xBFFFFFFF Для кода и данных 0x800000000 xC0000000 x00000400 00000000 xC0000000 режима ядра xFFFFFFFF 0xFFFFFFFF xFFFFFFFF FFFFFFFF xFFFFFFFF Таблица 13-1. Так адресное пространство процесса разбивается на разделы Раздел для выявления нулевых указателей (Windows 2000 и Windows 98) Этот раздел адресного пространства резервируется для того, чтобы программисты могли выявлять нулевые указатели. Любая попытка чтения или записи в память по этим адресам вызывает нарушение доступа. Довольно часто в программах, написанных на С/С++, отсутствует скрупулезная обработки ошибок. Например, в следующем фрагменте кода такой обработки вообще нет: int* pnSomeInteger = (int*) malloc(sizeof(int)); *pnSomeInteger = 5; При нехватке памяти malloc вернет NULL. Ho код не учитывает эту возможность и при ошибке обратится к памяти по адресу 0x00000000 А поскольку этот раздел адресного пространства заблокирован, возникнет нарушение доступа и данный процесс завершится Эта особенность помогает программистам находить "жучков* в своих приложениях. В Windows 2000 программы для MS-DOS и 16-разрядной Windows выполняются в собственных адресных пространствах; 32-разрядные приложения повлиять на них не могут. Раздел для кода и данных пользовательского режима (Windows 2000 и Windows 98) В этом разделе располагается закрытая (неразделяемая) часть адресного пространства процесса. Ни один процесс не может получить доступ к данным другого процесса, размещенным в этом разделе. Основной объем данных, принадлежащих процессу, хранится именно здесь (это касается всех приложений) Поэтому приложения менее зависимы от взаимных "капризов", и вся система функционирует устойчивее. В Windows 2000 сюда загружаются все EXE- и DLL-модули В каждом процессе эти DLL можно загружать по разным адресам в пределах данного раздела, но так делается крайне редко. На этот же раздел отображаются все проецируемые в память файлы, доступные данному процессу. В 64- разрядной Windows 2000 ядро наконец получит то пространство, которое ему нужно на самом деле. Увеличение раздела для кода и данных пользовательского режима до 3 Гб на процессорах x86 (только Windows 2000) Microsoft предусмотрела в версиях Windows 2000 Advanced Server и Windows 2000 Data Center для процессоров x86 возможность увеличения этого пространства до 3 Гб. Чтобы все процессы использовали раздел для кода и данных пользовательского режима размером 3 Гб, а раздел для кода и данных режима ядра —объемом 1 Гб, Вы должны добавить ключ /3GB к нужной записи в системном файле Boot.ini. Как выглядит адресное пространство процесса в этом случае, показано в графе "32-разрядная Windows 2000 (на x86 с ключом /3GB)" таблицы 13-1. Уменьшение раздела для кода и данных пользовательского режима до 2 Гб в 64- разрядной Windows 2000 Многие разработчики захотят как можно быстрее перенести свои 32-разрндные приложения в 64-разрядную среду. Но в исходном коде любых программ полно таких мест, Когда EXE- или DLL-файл загружается с дискеты Windows 2000 целиком копируют его в оперативную память, а в страничном файле выделяют такое пространство, чтобы в нем мог уместиться образ загружаемого файла. Если нагрузка на оперативную память в системе невелика, EXE- или DLLфайл всегда запускается непосредственно из оперативной памяти.Так сделано для корректной работы программ установки. Обычно программа установки запускается с первой дискеты, потом поочередно вставляются следующие диски, на которых собственно и содержится устанавливаемое приложение. Если системе понадобится какой-то фрагмент кода EXE- или DLLмодуля программы установки, на текущей дискете его, конечно же, пет. Но, поскольку система скопировала файл в оперативную память (и предусмотрела для него место в страничном файле), у нее не возникнет проблем с доступом к нужной части кода программы установки Атрибуты защиты Отдельным страницам физической памяти можно присвоить свои атрибуты защиты показанные в следующей таблице. Атрибут защиты Описание PAGE_NOACCESS Попытки чтения, записи или исполнения содержимого памяти на этой странице вызывают нарушение доступа PAGE_READONLY Попытки записи или исполнения содержимого памяти на этой странице вызывают нарушение доступа PAGE_READWRITE Попытки исполнения содержимого памяти на этой странице вызывают нарушение доступа PAGE_EXECUTE Попытки чтения или записи на этой странице вызывают нарушение доступа PAGE_EXECUTE_READ Попытки записи на этой странице вызывают нарушение доступа PAGE_EXECUTE_READWRITE На этой странице возможны любые операции PAGE_WRITECOPY Попытки исполнения содержимого памяти на этой странице выбывают нарушение доступа, попытка записи приводит к тому, что процессу предоставляется "личная" копия данной страницы PAGE_EXECUTE_WRITECOPY На этой странице возможны любые операции, попытка записи приводит к тому, что процессу предоставляется "личная" копия данной страницы Защита типа "копирование при записи" Атрибуты защиты, перечисленные в предыдущей таблице, достаточно понятны, кроме двух последних: PAGE_WRITECOPY и PAGE_EXECUTE_WRITECOPY. Они предназначены специально для экономного расходования оперативной памяти и места в страничном файле. Windows поддерживает мехянизм, позволяющий двум и более процессам разделять один и тот же блок памяти. Например, если Вы запустите 10 экземпляров программы Notepad, все экземпляры будут совместно использовать одни и те же страницы с кодом и данными этой программы. И обычно никяких проблем не возникает —пока процессы ничего не записывают в общие блоки памяти. Только представьте, что творилось бы в системе, если потоки из разных процессов начали бы одновременно записывать в один и тот же блок памяти! Чтобы предотвратить этот хаос, операционная система присваивает общему блоку памяти атрибут защиты "копирование при записи" (copy-on-write). Когда поток в одном процессе попытается что-нибудь записать в общий блок памяти, в дело тут же вступит система и проделает следующие операции: Найдет свободную страницу в оперативной памяти. Заметьте, что при первом проецировании модуля на адресное пространство процесса эта страница будет скопирована на одну из страниц, выделенных в страничном файле. Поскольку система выделяет нужное пространство в страничном файле еще при первом проецировании модуля, сбои на этом этапе маловероятны. Скопирует страницу с данными, которые поток пытается записать в общий блок памяти, на свободную страницу оперативной памяти, полученную на этапе 1. Последней присваивается атрибут защиты PAGE_WRITECOPY или PAGE_EXECUTE_WRITECOPY. Атрибут защиты и содержимое исходной страницы не меняются. Отобразит виртуальный адрес этой страницы в процессе на новую страницу в оперативной памяти. Когда система выполнит эти операции, процесс получит свою копию нужной страницы памяти. Кроме того, при резервировании адресного пространства или передаче физической памяти через VirtualAlloc нельзя указывать атрибуты PAGE_WRITECOPY или PAGE_EXECUTE_WRITECOPY. Иначе вызов VirtualAlloc даст ошибку, a GetLastError вернет код ERROR_INVALID_PARAMETER. Дело в том, что эти два атрибута используются операционной системой, только когда она проецирует образы EXE- или DLL-файлов. Базовый адрес Тип Размер Блоки Атрибут( ы) защиты Описание 00000000 Free 00010000 Private -RW- 00011000 Free G1440 00020000 Private -RW- 000? 1000 Free 00030000 Private -HW- Стек потока 00130000 Private -RW- 00230000 Mapped -RW- 00240000 Mapped -R- \Device \HarddiskVolu me1\WINN7 \system32 \unicode.nls 00256000 Free 00260000 Mapped -R- \Device \HarddiskVolu me1\WINNT \system32 \locale.nIs 00293000 Free 002A0000 Happed -R- \Pevicc \HarddiskVolu me1\WINNT \system32 \sortkey.nls 002E1000 Free 002F0000 Mapped -R- \Device \HarddiskVolu me1\WINNT \system32 \sorttbls.nls 002F4000 Free 00300000 Mapped ER- 0003С8000 Free 00400000 Image ERWC С \CD\x86 \Debug \14_VMMap.ех е 0041A000 Free 00420000 Mapped -R- 00463000 Free 00470000 Mapped ER 00770000 Private -RW- 00771000 Free 00780000 Private -RW- 00781000 Free 00790000 Private -RW- 007A0000 Mapped -R- \Device \HarddiskVolu me1\WINNT \system32 \ctype.nls 007А2000 Free 699D0000 Image ERWC C:\WINNT \Systpm32 \PSAPI dll 6990В000 Free 77D50000 Image ERWC С:\WINNT \system32 \RPCRT4 DLL 770ВЕ000 Free 770С0000 Image ERWC С:\WINNT \system32 \ADVAPI32 dll 77Е14000 Free 77E20000 Image ERWC C:\WINNT \system32 \USER32 dll 77Е82000 Free 77Е90000 Image ERWC С \WINNT \system32 \KERNEL32.dl l 77F40000 Image ERWC С \WINKT \system32 \GUI32 DLL 00230000 Mapped -RW- —— 00231000 Reserve -RW- --- 00240000 Mapped -R — \Device \HarddiskVoluu me1\WTNNT \system32 \unicode.nls 00240000 Happed R 00256000 Free GO 00260000 Mapped -R-- \Device \HarddiskVoluu me1\WTNNT \system32 \locale.nls 00260000 Mapped -R-- --- 00293000 Free 002А0000 Happed -R — \Device \HarddiskVoluu me1\WTNNT \system32 \sortkey.nls 002А0000 Mapped -R-- --- 002Е1000 Free 002F0000 Mapped -R- \Device \HarddiskVoluu me1\WTNNT \system32 \sorttbls.nls 002F0000 Mapped -R-- --- 002F4000 Free 00300000 Mapped ER- 00300000 Mapped ЕR-- —-- 00304000 Reserve ER-- --- 003C0000 Mapped ER-- --- ОО3С2000 Reserve ER-- --- ОО3С8000 Free 00400000 Image ERWC С:\CD\x86 \Debug \14_VMMap.ex e 00400000 Image -R-- --- 00401000 Image ЕR-- —-- 00415000 Image -R-- --- 00416000 Image -RW- --- 00418000 Image -R-- --- 0041А000 Free 00420000 Mapped -R- 00420000 Mapped -R- --- 00463000 Free 00470000 Mapped ER-- 00470000 Mapped ER-- --- 004B3000 Reserve ER-- --- 00770000 Private -RW- --- 00770000 Privale -RW- --- 00771000 Free 00780000 Pr ivate -RW- --- 00780000 Private -RW- --- 00781000 Free 00790000 Private -RW- --- 00790000 Private -RW- --- 00795000 Reserve -RW- --- 007А0000 Mapped -R-- --- \Device \HarddiskVolu me1\WINNT \system32 \ctype.nls 007А0000 Mapped -R-- --- 007A2000 Free 007В0000 Private -RW- --- 007В0000 Private -RW- --- 007В1000 Reserve -RW- --- 00830000 Free 699D0000 Image ERWC С:\WINNT \Systern32 \PSAPI.dll 699D0000 Image -R-- --- 69901000 Image ER- --- 699D5000 Image -RWC --- 699D9000 Image -R-- --- 699DB000 Free 77D50000 Imago ERWC C:\WINNT \system32 \RPCRT4.DLL 77D50000 Image -R-- --- 77D51000 image ER-- --- 77DB8000 Image G -RW- --- 77DB9000 Image -R-- --- 77DBE000 Free 77DC0000 Image ERWC С:\WINNT \syatem32 \ADVAPI32.dll 77DC0000 Image -R-- --- 77DС1000 Image ER-- --- 77Е0С000 Image -RW- --- 77E00000 Image -RWC --- 77Е0E000 Image -R-- --- 77Е14000 Free 77E20000 Image ERWC С:\WINNT \system32 \USER32.dll /7Е20000 Image -R-- --- 77Е21000 Image ER-- --- 77Е76000 Image -RW- --- 77Е77000 Image -R-- --- 77Е82000 Free 77Е90000 Image ERWC С \WINNT \system32 \KERNEL32.dl l 77Е90000 Image -R-- --- 77Е91000 Image ER-- --- 77ЕЕВ000 Image -RW- --- 77EED000 Image -RWC --- 77ЕЕЕ000 Image -R-- --- 77F40000 Image ERWC С \WINNT \system32 \GDI32.DLL 77F40000 Image -R-- --- 77F41000 Image ER-- --- 77F77000 Image -RW- --- 77F78000 Image -R-- --- 77F7B000 Free 77F80000 Image ERWC С \WINT \System32 \ntdll.dll 77F80000 Image b -R-- --- 77F81000 Image ER-- --- 77FCA000 Image RW- --- 77FCC000 Image -RWC --- 77FCD000 Image -R-- --- 77FF6000 Free 78000000 Image ERWC С \WINNT \system32 \MSVCRT.dll 78000000 Image -R-- --- 78001000 Image ER-- --- 78031000 Image -R-- --- 7803С000 Image -RW- --- 7803F000 Image -RWC --- 78043000 Image -R-- --- 78047000 Free 7F6F0000 Mapped ER-- --- 7F6F0000 Mapped ER-- --- 7F6F7000 Reserve ER-- --- 7F7F0000 Free