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

Ответ 1

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

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

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

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

Я мог бы ошибаться здесь, но я бы поставил на то, что вещи, которые вам трудно обмануть, связаны с конкретными реализациями виртуальной памяти, скорее всего, поисковыми вызовами. Существует не один способ для создания подкачки - существует много реализаций, и тот, который описывает ваш учебник, скорее всего не совпадает с тем, который появляется в реальных операционных системах, таких как Linux/Windows, - есть, вероятно, тонкие различия.

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

Ответ 2

Программное обеспечение работает в ОС с очень простой предпосылкой - им требуется память. ОС устройства предоставляет его в виде оперативной памяти. Требуемый объем памяти может варьироваться - некоторым программам нужна огромная память, другим - мизерная память. Большинство (если не все) пользователи одновременно запускают несколько приложений в ОС, и, учитывая, что память дорогая (а размер устройства конечен), объем доступной памяти всегда ограничен. Таким образом, учитывая, что для всех программ требуется определенный объем ОЗУ, и все они могут работать одновременно, ОС должна позаботиться о двух вещах:

1. Это программное обеспечение всегда запускается до тех пор, пока пользователь не прервет его, то есть оно не должно автоматически прерываться, потому что ОС не хватает памяти.
2. Вышеуказанные действия, сохраняя при этом респектабельную производительность для работающих программ.

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

Возможное решение 1. Разрешите отдельным программам явно указывать адрес памяти, который они будут использовать в устройстве. Предположим, Photoshop заявляет, что он всегда будет использовать адреса памяти в диапазоне от 0 до 1023 (представьте, что память представляет собой линейный массив байтов, поэтому первый байт находится в ячейке 0, 1024 й байт находится в ячейке 1023), то есть занимает 1 GB памяти. Аналогично, VLC заявляет, что он будет занимать диапазон памяти от 1244 до 1876 и т.д.

Преимущества:

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

Недостатки:

1. Это не масштабируется. Теоретически, приложению может потребоваться огромное количество памяти, когда оно выполняет что-то действительно тяжелое. Таким образом, чтобы гарантировать, что он никогда не исчерпает память, выделенная ему область памяти всегда должна быть больше или равна этому объему памяти. Что если программное обеспечение, чье максимальное теоретическое использование памяти составляет 2 GB (следовательно, требуется 2 GB выделения памяти из ОЗУ), установлено на машине, имеющей только 1 GB памяти? Должно ли программное обеспечение просто прерываться при запуске, говоря, что доступная оперативная память составляет менее 2 GB? Или это должно продолжаться, и в тот момент, когда требуемая память превышает 2 GB, просто прервитесь и выведите сообщение о том, что недостаточно памяти?

2. Невозможно предотвратить искажение памяти. Существуют миллионы программ, даже если каждому из них было выделено всего 1 kB памяти, общий объем требуемой памяти превысил бы 16 GB, что больше, чем предлагает большинство устройств. Как же тогда разным программам можно выделить слоты памяти, которые не затрагивают друг друга? Во-первых, нет централизованного рынка программного обеспечения, который мог бы регулировать то, что при выпуске нового программного обеспечения он должен выделять себе столько памяти из этой еще не занятой области, а во-вторых, даже если бы он был, это невозможно сделать, потому что нет. программного обеспечения практически бесконечна (таким образом, требуется бесконечная память для размещения всех из них), и общего объема оперативной памяти, доступной на любом устройстве, недостаточно для размещения даже части того, что требуется, что делает неизбежным вторжение в пределы памяти одного программного обеспечения на это другого. Так что же происходит, когда Photoshop назначается область памяти от 1 до 1023 а VLC назначается от 1000 до 1676? Что если Photoshop хранит некоторые данные в местоположении 1008, тогда VLC перезаписывает их своими собственными данными, и позже Photoshop обращается к ним, думая, что это те же самые данные, которые хранились там ранее? Как вы можете себе представить, плохие вещи будут происходить.

Так ясно, как видите, эта идея довольно наивна.

Возможное решение 2: Давайте попробуем другую схему - где ОС будет делать большую часть управления памятью. Программное обеспечение, когда ему требуется какая-либо память, просто запрашивает ОС, и ОС будет приспосабливаться соответственно. Скажем, ОС гарантирует, что всякий раз, когда новый процесс запрашивает память, она выделяет память из минимально возможного байтового адреса (как было сказано ранее, ОЗУ можно представить как линейный массив байтов, поэтому для ОЗУ 4 GB диапазон адресов для байта от 0 до 2^32-1) если процесс запускается, иначе, если это запущенный процесс, запрашивающий память, он будет выделяться из последней области памяти, где этот процесс все еще находится. Поскольку программное обеспечение будет отправлять адреса без учета того, каким будет фактический адрес памяти, где хранятся эти данные, ОС должна будет поддерживать отображение для каждого программного обеспечения адреса, испускаемого программным обеспечением, на фактический физический адрес (Примечание: это одна из двух причин, по которым мы называем эту концепцию Virtual Memory программам не важен реальный адрес памяти, где хранятся их данные, они просто выкладывают адреса на лету, и ОС находит подходящее место для этого и найдите его позже, если потребуется).

Скажем, устройство только что включилось, ОС только что запустилась, сейчас нет другого запущенного процесса (игнорируя ОС, который также является процессом!), И вы решаете запустить VLC. Таким образом, VLC выделяется часть оперативной памяти из младших байтовых адресов. Хорошо. Теперь, пока идет видео, вам нужно запустить браузер для просмотра какой-либо веб-страницы. Затем вам нужно запустить Блокнот, чтобы набросать текст. И затем Eclipse, чтобы сделать некоторое кодирование. Довольно скоро ваша память 4 GB полностью израсходована, и ОЗУ выглядит следующим образом:

Проблема 1: Теперь вы не можете запустить любой другой процесс, так как вся оперативная память израсходована. Таким образом, программы должны быть написаны с учетом максимальной доступной памяти (практически даже меньше будет доступно, так как другие программы будут работать параллельно!). Другими словами, вы не можете запустить приложение с высоким потреблением памяти на своем ветхом ПК 1 GB.

Итак, теперь вы решаете, что вам больше не нужно держать Eclipse и Chrome открытыми, вы закрываете их, чтобы освободить часть памяти. Пространство, занимаемое этими процессами в оперативной памяти, используется ОС, и теперь это выглядит так:

Предположим, что эти два освобождают 700 MB пространства - (400 + 300) МБ. Теперь вам нужно запустить Opera, которая займет 450 MB пространства. Что ж, у вас есть в общей сложности более 450 MB свободного места, но... оно не является смежным, оно разделено на отдельные куски, ни один из которых не достаточно большой, чтобы вместить 450 MB. Таким образом, вы натолкнулись на блестящую идею, позвольте переместить все процессы ниже как можно выше, чтобы оставить 700 MB пустого пространства в одном блоке внизу. Это называется compaction. Отлично, разве что... все процессы, которые там есть, запущены. Перемещение их будет означать перемещение адреса всего их содержимого (помните, ОС поддерживает отображение памяти, выделяемой программным обеспечением, на фактический адрес памяти. Представьте, что программное обеспечение выдало адрес 45 с данными 123, а ОС сохранила его в местоположении 2012 и создал запись на карте, сопоставляя 45 с 2012 Если программное обеспечение теперь перемещено в памяти, то, что было в местоположении 2012, больше не будет в 2012, но в новом местоположении, и ОС должна будет обновить карта соответствует карте 45 с новым адресом, так что программное обеспечение может получить ожидаемые данные (123), когда оно запрашивает ячейку памяти 45 Что касается программного обеспечения, все, что ему известно, это то, что адрес 45 содержит данные 123 !)! Представьте себе процесс, который ссылается на локальную переменную i. К тому времени, когда к нему снова получат доступ, его адрес изменится, и он больше не сможет его найти. То же самое относится ко всем функциям, объектам, переменным, в основном все имеют адрес, и перемещение процесса будет означать изменение адреса всех из них. Что приводит нас к:

Проблема 2: Вы не можете переместить процесс. Значения всех переменных, функций и объектов в этом процессе имеют жестко заданные значения, которые выводятся компилятором во время компиляции, процесс зависит от того, находятся ли они в одном и том же месте в течение своего времени жизни, и их изменение обходится дорого. В результате процессы оставляют после себя большие " holes ". Это называется External Fragmentation.

Хорошо. Предположим, каким-то чудесным образом вам удалось продвинуть процессы вверх. Теперь внизу 700 MB свободного места:

Опера плавно вписывается внизу. Теперь ваша RAM выглядит так:

Хорошо. Все выглядит хорошо. Тем не менее, осталось не так много места, и теперь вам нужно снова запустить Chrome, известного бога памяти! Для запуска требуется много памяти, и у вас почти ничего не осталось... За исключением того, что... теперь вы заметили, что некоторым процессам, которые первоначально занимали большое пространство, теперь не нужно много места. Возможно, вы остановили свое видео в VLC, следовательно, оно все еще занимает некоторое место, но не так много, как требуется для работы с видео высокого разрешения. Аналогично для блокнота и фотографий. Ваша RAM теперь выглядит так:

Holes, еще раз! Возвращается на круги своя! За исключением того, что раньше дыры возникали из-за прекращения процессов, а теперь из-за процессов, требующих меньше места, чем раньше! И у вас опять та же проблема: объединенные holes дают больше места, чем требуется, но они разбросаны вокруг, и не так много используются в изоляции. Таким образом, вам придется снова перемещать эти процессы, что является дорогостоящей и очень частой операцией, поскольку процессы часто уменьшаются в размерах в течение срока службы.

Проблема 3: Процессы в течение срока их службы могут уменьшаться в размерах, оставляя неиспользуемое пространство, которое, в случае необходимости, потребует дорогостоящей операции перемещения многих процессов. Это называется Internal Fragmentation.

Хорошо, теперь ваша ОС выполняет необходимые действия, перемещает процессы и запускает Chrome, а через некоторое время ваша RAM выглядит следующим образом:

Здорово. Теперь предположим, что вы снова возобновили просмотр Аватара в VLC. Его требование к памяти будет расти! Но... ему не осталось места для роста, поскольку Блокнот прижимается к его нижней части. Итак, опять же, все процессы должны двигаться ниже, пока VLC не найдет достаточно места!

Проблема 4: Если процессы должны расти, это будет очень дорогая операция

Хорошо. Теперь предположим, что Фото используется для загрузки некоторых фотографий с внешнего жесткого диска. Доступ к жесткому диску переносит вас из области кэшей и ОЗУ в область диска, которая на несколько порядков медленнее. Уж больно, бесповоротно, заоблачно медленнее. Это операция ввода-вывода, которая означает, что она не связана с процессором (это скорее полная противоположность), что означает, что ей не нужно сейчас занимать ОЗУ. Тем не менее, она по-прежнему занимает RAM упорно. Если вы хотите запустить Firefox в то же время, вы не можете этого сделать, потому что не так много памяти доступно, в то время как если бы фотографии были удалены из памяти на время действия, связанного с вводом/выводом, это освободило бы много памяти, с последующим (дорогим) уплотнением, за которым следует вставка Firefox.

Проблема 5: Задания, связанные с вводом/выводом, продолжают занимать ОЗУ, что приводит к недостаточному использованию ОЗУ, которое в то же время могло использоваться заданиями, связанными с ЦП.

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

Существует два подхода к решению этих проблем - paging и segmentation. Давайте обсудим paging. При таком подходе виртуальное адресное пространство процесса отображается на физическую память порциями - так называемыми pages. Типичный размер page составляет 4 kB. Сопоставление поддерживается с помощью чего-то, называемого page table, с учетом виртуального адреса. Теперь все, что нам нужно сделать, это выяснить, к какой page принадлежит адрес, а затем из page table найти соответствующее местоположение для этой page в реальной физической памяти ( известный как frame), и учитывая, что смещение виртуального адреса на page одинаково для page и frame, определите фактический адрес, добавив это смещение к адресу, возвращенному page table. Например:

Слева - виртуальное адресное пространство процесса. Скажем, виртуальное адресное пространство требует 40 единиц памяти. Если бы в физическом адресном пространстве (справа) также было 40 единиц памяти, было бы возможно отобразить все местоположения слева на местоположение справа, и мы были бы очень рады. Но, как не повезло, физическая память не только имеет меньше (24 здесь) доступных блоков памяти, но и должна быть распределена между несколькими процессами! Хорошо, давайте посмотрим, как мы справимся с этим.

Когда процесс начинается, скажем, сделан запрос доступа к памяти для местоположения 35. Здесь размер страницы составляет 8 (каждая page содержит 8 местоположений, таким образом, все виртуальное адресное пространство из 40 местоположений содержит 5 страниц). Так что это место принадлежит странице №. 4 (35/8). На этой page это местоположение имеет смещение 3 (35%8). Таким образом, это местоположение может быть указано с помощью кортежа (pageIndex, offset)= (4,3). Это только начало, поэтому никакая часть процесса еще не сохранена в реальной физической памяти. Таким образом, page table, которая поддерживает отображение страниц слева на фактические страницы справа (где они называются frames), в настоящее время пуста. Таким образом, ОС освобождает процессор, позволяет драйверу устройства получить доступ к диску и получить страницу №. 4 для этого процесса (в основном это фрагмент памяти программы на диске с адресами от 32 до 39). Когда он поступает, ОС выделяет страницу где-то в ОЗУ, скажем, сам первый кадр, и page table для этого процесса принимает к сведению, что страница 4 отображается в 0 кадр в ОЗУ. Теперь данные наконец-то есть в физической памяти. ОС снова запрашивает таблицу страниц для кортежа (4,3), и на этот раз таблица страниц говорит, что страница 4 уже сопоставлена с кадром 0 в ОЗУ. Таким образом, ОС просто переходит к 0 му кадру в ОЗУ, получает доступ к данным со смещением 3 в этом кадре (Найдите минутку, чтобы понять это. Вся page, которая была извлечена с диска, перемещается в frame. Так что, независимо от смещения Индивидуальное расположение памяти на странице было, оно будет таким же и во фрейме, поскольку внутри page/ frame блок памяти все еще находится в одном и том же месте относительно!) и возвращает данные! Поскольку данные не были найдены в памяти при первом запросе, а скорее должны были быть извлечены с диска для загрузки в память, это является пропуском.

Хорошо. Теперь предположим, что доступ к памяти для местоположения 28 сделан. Это сводится к (3,4). Page table сейчас имеет только одну запись, отображающую страницу 4 в кадр 0. Так что это снова промах, процесс освобождает процессор, драйвер устройства извлекает страницу с диска, процесс снова восстанавливает управление процессором, и его page table обновляется. Скажем, теперь страница 3 сопоставлена с кадром 1 в ОЗУ. Таким образом, (3,4) становится (1,4), и данные в этом месте в ОЗУ возвращаются. Хорошо. Таким образом, предположим, что следующий доступ к памяти для местоположения 8, что переводится в (1,0). Страница 1 еще не находится в памяти, та же самая процедура повторяется, и page выделяется в кадре 2 в ОЗУ. Теперь отображение RAM-процесса выглядит как на картинке выше. На данный момент ОЗУ, в котором было доступно только 24 единицы памяти, заполнено. Предположим, что следующий запрос доступа к памяти для этого процесса с адреса 30. Он отображается на (3,6), а page table говорит, что страница 3 находится в ОЗУ, и отображается на кадр 1. Ура! Таким образом, данные выбираются из ОЗУ (1,6) и возвращаются. Это является хитом, поскольку требуемые данные могут быть получены непосредственно из ОЗУ, что делает их очень быстрыми. Аналогично, следующие несколько запросов доступа, скажем, для местоположений 11, 32, 26, 27 все являются попаданиями, то есть данные, запрошенные процессом, находятся непосредственно в ОЗУ без необходимости искать в другом месте.

Теперь предположим, что запрос на доступ к памяти для местоположения 3 приходит. Это переводит в (0,3), и page table для этого процесса, которая в настоящее время имеет 3 записи, для страниц 1, 3 и 4 говорит, что эта страница не находится в памяти. Как и в предыдущих случаях, он извлекается с диска, однако, в отличие от предыдущих случаев, ОЗУ заполнено! Так что же теперь делать? Здесь кроется красота виртуальной памяти, кадр из ОЗУ выселен! (Различные факторы определяют, какой кадр должен быть удален. Он может быть основан на LRU, где должен быть LRU кадр, к которому был осуществлен наименьший доступ для процесса. Это может быть принцип " first-come-first-evicted, где кадр, который выделил давным-давно выселяют и т.д.) Так что некоторые рамки выселяют. Скажите кадр 1 (просто случайно выбрав его). Тем не менее, этот frame отображается на какой-то page ! (В настоящее время это отображается в таблице страниц нашего единственного и единственного процесса на странице 3). Таким образом, этому процессу нужно сообщить эту трагическую новость, что один frame, который, к сожалению, принадлежит вам, должен быть удален из ОЗУ, чтобы освободить место для других pages. Процесс должен убедиться, что он обновляет свою page table с этой информацией, то есть удаляет запись для этого дуэта фрейма страницы, чтобы в следующий раз, когда запрос был сделан для этой page, он правильно сообщил процессу, что эта page больше не в памяти, и должен быть извлечен с диска. Хорошо. Таким образом, кадр 1 является выселен, страница 0 вносится в и помещена там в RAM, а также запись для страницы 3 удаляется и заменяется на странице 0 отображения одной и ту же рамку 1. Итак, теперь наше отображение выглядит следующим образом (обратите внимание на изменение цвета во втором frame с правой стороны):

Видел, что только что произошло? Процесс должен был расти, ему требовалось больше места, чем доступной оперативной памяти, но в отличие от нашего более раннего сценария, когда каждый процесс в оперативной памяти должен был перемещаться, чтобы приспособиться к растущему процессу, здесь это происходило всего лишь одной заменой page ! Это стало возможным благодаря тому факту, что память для процесса больше не должна быть смежной, она может находиться в разных местах по частям, ОС хранит информацию о том, где они находятся, и при необходимости их запрашивают соответствующим образом. Примечание: вы можете подумать, а что если в большинстве случаев это miss, и данные должны постоянно загружаться с диска в память? Да, теоретически это возможно, но большинство компиляторов спроектировано таким образом, что следует locality of reference, т.е. если используются данные из некоторого места в памяти, следующие необходимые данные будут расположены где-то очень близко, возможно, с той же page, page которая была только что загружена в память. В результате следующая ошибка произойдет через некоторое время, большинство предстоящих требований к памяти будут удовлетворены только что введенной страницей или уже существующими в памяти страницами, которые были недавно использованы. Точно такой же принцип позволяет нам исключить и наименее использованную page, с той логикой, что то, что не было использовано какое-то время, вряд ли будет использовано и в ближайшее время. Однако это не всегда так, и в исключительных случаях да, производительность может пострадать. Подробнее об этом позже.

Решение проблемы 4: теперь процессы могут легко расти, если возникает проблема с пространством, все, что требуется, это сделать простую замену page, не перемещая какой-либо другой процесс.

Решение проблемы 1: процесс может получить доступ к неограниченной памяти. Когда требуется больше памяти, чем доступно, диск используется в качестве резервной копии, новые требуемые данные загружаются в память с диска, а наименее использованный frame данных (или page) перемещается на диск. Это может продолжаться бесконечно, а поскольку дисковое пространство дешево и практически не ограничено, это создает иллюзию неограниченной памяти. Еще одна причина для названия Virtual Memory, это дает вам иллюзию памяти, которая на самом деле не доступна!

Здорово. Ранее мы сталкивались с проблемой, когда хотя процесс уменьшается в размерах, пустое пространство трудно утилизировать другими процессами (поскольку это потребовало бы дорогостоящего уплотнения). Теперь легко, когда процесс становится меньше по размеру, многие его pages больше не используются, поэтому, когда другим процессам требуется больше памяти, простое выселение на основе LRU автоматически вытесняет эти менее используемые pages из ОЗУ и заменяет их новые страницы из других процессов (и, конечно, обновление page tables всех этих процессов, а также исходного процесса, который теперь требует меньше места), все это без какой-либо дорогостоящей операции уплотнения!

Решение проблемы 3: Всякий раз, когда процессы уменьшаются в размере, их frames в оперативной памяти будут использоваться реже, поэтому простое выселение на основе LRU может выселить эти страницы и заменить их pages необходимыми для новых процессов, что позволит избежать Internal Fragmentation без необходимости compaction.

Что касается проблемы 2, найдите время, чтобы понять это, сам сценарий полностью удален! Нет необходимости перемещать процесс, чтобы приспособить новый процесс, потому что теперь весь процесс никогда не должен соответствовать сразу, только определенные его страницы должны соответствовать ad hoc, что происходит путем удаления frames из ОЗУ. Все происходит в единицах pages, таким образом, теперь нет понятия hole, и, следовательно, не может быть и речи о том, что движется! Может быть, пришлось переместить 10 pages из-за этого нового требования, тысячи pages остались нетронутыми. Принимая во внимание, что ранее, все процессы (каждый бит) должны были быть перемещены!

Решение проблемы 2: Чтобы приспособить новый процесс, данные из только что использовавшихся в последнее время частей других процессов должны быть удалены по мере необходимости, и это происходит в единицах фиксированного размера, называемых pages. Таким образом, нет никакой возможности hole или External Fragmentation с этой системой.

Теперь, когда процессу требуется выполнить некоторые операции ввода-вывода, он может легко освободить процессор! ОС просто удаляет все свои pages из ОЗУ (возможно, хранит его в некотором кеше), в то время как новые процессы занимают ОЗУ. Когда операция ввода/вывода завершена, ОС просто восстанавливает эти pages в ОЗУ (конечно, путем замены pages из некоторых других процессов, может быть из тех, которые заменили исходный процесс, или из тех, которые сами должны сделать I/O сейчас и, следовательно, может отказаться от памяти!)

Решение проблемы 5. Когда процесс выполняет операции ввода-вывода, он может легко отказаться от использования ОЗУ, которое может использоваться другими процессами. Это приводит к правильному использованию оперативной памяти.

И, конечно же, сейчас ни один процесс не имеет прямого доступа к оперативной памяти. Каждый процесс обращается к расположению виртуальной памяти, которое отображается на физический адрес ОЗУ и поддерживается page-table этого процесса. Отображение поддерживается ОС, ОС позволяет процессу узнать, какой фрейм пуст, так что новая страница процесса может быть размещена там. Поскольку это выделение памяти контролируется самой ОС, оно может легко гарантировать, что ни один процесс не посягает на содержимое другого процесса, выделяя только пустые кадры из ОЗУ или, покушаясь на содержимое другого процесса в ОЗУ, связывается с процессом. обновить его page-table.

Решение исходной проблемы: нет возможности доступа процесса к содержимому другого процесса, так как все распределение управляется самой ОС, и каждый процесс выполняется в своем собственном изолированном виртуальном адресном пространстве.

Таким образом, paging (среди прочих методов) в сочетании с виртуальной памятью - вот то, что обеспечивает сегодня программное обеспечение, работающее на ОС! Это освобождает разработчика программного обеспечения от беспокойства о том, сколько памяти доступно на пользовательском устройстве, где хранить данные, как предотвратить повреждение данных своего программного обеспечения другими процессами и т.д. Однако это, конечно, не полная проверка. Есть недостатки:

1. Paging, в конечном счете, дает пользователю иллюзию бесконечной памяти, используя диск в качестве вторичной резервной копии. Извлечение данных из вторичного хранилища для помещения в память (это называется page swap, а событие, когда не удается найти нужную страницу в ОЗУ, называется page fault), является дорогостоящим процессом, поскольку это операция ввода-вывода. Это замедляет процесс. Несколько таких обменов страниц происходят последовательно, и процесс становится мучительно медленным. Вы когда-нибудь видели, чтобы ваше программное обеспечение работало нормально и внезапно, и вдруг оно стало настолько медленным, что почти зависало, или не оставляло вам возможности перезапустить его? Возможно, происходило слишком много перестановок страниц, что делало его медленным (так называемый thrashing).

Итак, возвращаясь к OP,

Зачем нам нужна виртуальная память для выполнения процесса? - Как подробно объясняется в ответе, дать программам иллюзию устройства/ОС, имеющего бесконечную память, чтобы можно было запускать любое программное обеспечение, большое или маленькое, не беспокоясь о распределении памяти или других процессах, повреждающих свои данные, даже когда работает параллельно. Это концепция, реализованная на практике с помощью различных методов, одним из которых, как описано здесь, является пейджинг. Это также может быть сегментация.

Где находится эта виртуальная память, когда процесс (программа) с внешнего жесткого диска переносится в основную память (физическую память) для выполнения? - Виртуальная память нигде не стоит сама по себе, это абстракция, всегда присутствующая, когда программное обеспечение/процесс/программа загружается, для нее создается новая таблица страниц, и она содержит отображение из адресов, выделенных этим обрабатывать фактический физический адрес в оперативной памяти. Поскольку адреса, выдаваемые процессом, не являются реальными, в некотором смысле они фактически являются, как вы можете сказать, the virtual memory.

Кто заботится о виртуальной памяти и каков размер виртуальной памяти? - Об этом заботятся, в тандеме, ОС и программное обеспечение. Представьте себе функцию в вашем коде (которая в конечном итоге скомпилирована и превращена в исполняемый файл, который породил процесс), которая содержит локальную переменную - int i. Когда код выполняется, i получаю адрес памяти в стеке функции. Эта функция сама хранится как объект где-то еще. Эти адреса генерируются компилятором (компилятор, который компилировал ваш код в исполняемый файл) - виртуальные адреса. При выполнении i должен находиться где-то в реальном физическом адресе, по крайней мере, в течение этой функции (если только она не является статической переменной!), Поэтому ОС отображает виртуальный адрес i сгенерированный компилятором, в фактический физический адрес, так что всякий раз, когда Эта функция, некоторый код требует значения i, этот процесс может запросить у ОС этот виртуальный адрес, а ОС, в свою очередь, может запросить у физического адреса сохраненное значение и вернуть его.

Предположим, если размер оперативной памяти составляет 4 ГБ (т.е. 2 ^ 32-1 адресных пространств), каков размер виртуальной памяти? - Размер оперативной памяти не связан с размером виртуальной памяти, он зависит от ОС. Например, в 32-битной Windows это 16 TB, в 64-битной Windows 256 TB. Конечно, он также ограничен размером диска, так как именно здесь резервируется память.

Ответ 3

Я беззастенчиво копирую выдержки из страницы руководства

VIRT - Virtual Image (kb) Общий объем виртуальной памяти, используемой задачей. Он включает в себя весь код, данные и общие библиотеки, а также страницы, которые были заменены, и страницы, которые были отображены, но не использовались.

SWAP - размер подкачки (КБ) Память, которая не является резидентной, но присутствует в задаче. Это память, которая была выгружена, но может включать дополнительную резидентную память non-. Этот столбец рассчитывается путем вычитания физической памяти из виртуальной памяти

Ответ 4

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

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

Ответ 5

Смотрите здесь: https://en.wikibooks.org/wiki/Operating_System_Design/Physical_Memory

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

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