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

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

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

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

возможное решение 1: пусть отдельные программные средства явно указывают адрес памяти, который они будут использовать в устройстве. Предположим Photoshop заявляет, что он всегда будет использовать адреса памяти, начиная от 0 до 1023 (представьте себе память в виде линейного массива байтов, поэтому первый байт находится в местоположении 0,1024th байт находится в местоположении 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 RAM, диапазон адресов для байта от 0 до 2^32-1) если процесс запускается, иначе, если это запущенный процесс, запрашивающий память, он выделит из последнего места памяти, где этот процесс все еще находится. Так как программное обеспечение будет излучать адреса без учета того, что фактический адрес памяти собирается там, где хранятся эти данные, ОС должна будет поддерживать отображение, в соответствии с программным обеспечением, адреса, излучаемого программным обеспечением, на фактический физический адрес (Примечание: это одна из двух причин, по которым мы называем эту концепцию Virtual Memory. Программное обеспечение не заботится о реальном адресе памяти, где хранятся их данные, они просто выплевывают адреса на лету, и ОС находит правильное место, чтобы соответствовать ему и найти его позже, если это необходимо).

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

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

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

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

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

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

Opera ровно вписывается в нижней части. Теперь ваш баран выглядит так:

хорошо. Все выглядит прекрасно. Тем не менее, осталось не так много места, и теперь вам нужно запустить Chrome опять же, известная память-свинья! Ему нужно много памяти, чтобы начать, и у вас почти ничего не осталось...Кроме.. теперь вы заметите, что некоторые процессы, которые изначально занимали большое пространство, теперь не нужны много места. Возможно, вы остановили свое видео в VLC, следовательно, он по-прежнему занимает некоторое пространство, но не столько, сколько требуется при запуске видео с высоким разрешением. Аналогично для Блокнот и фото. Ваш баран теперь выглядит так:

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

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

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

прохладный. Теперь предположим, что вы снова возобновить просмотр Аватар in 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 здесь) доступных блоков памяти, но и должна быть разделена между несколькими процессами! Ладно, посмотрим, как мы с этим справимся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

смотрите здесь: Физическая И Виртуальная Память

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