К сожалению, ответ «это зависит». Вы не упомянули операционную систему, но подразумевали linux, когда упоминали GDB. Я постараюсь быть полностью общим в своем ответе.
Существует три основных "адресных пространства".
Первое - это логическое адресное пространство. Это диапазон указателя. Современные (386 или выше) имеют блоки управления памятью, которые позволяют операционной системе отображать вашу фактическую (физическую) память по произвольным адресам. Для типичного настольного компьютера это делается кусками по 4 КБ. Когда программа обращается к памяти по какому-либо адресу, ЦП будет искать, где какой физический адрес соответствует этому логическому адресу, и кеширует его в TLB (буфер преобразования внешнего вида). Это допускает три вещи: во-первых, это позволяет операционной системе выделять каждому процессу столько адресного пространства, сколько ему нужно (вплоть до всего диапазона указателя - или выше, если есть API, позволяющие программам отображать / отменять отображение разделов своего адресного пространства. ). Во-вторых, он позволяет полностью изолировать разные программы, переключаясь на другое отображение памяти, что делает невозможным повреждение одной программы одной программой. В-третьих, он предоставляет разработчикам помощь в отладке - случайные поврежденные указатели могут указывать на какой-либо адрес, который вообще не был отображен, что приводит к «ошибке сегментации» или «ошибке неверной страницы» или любой другой терминологии, которая зависит от ОС.
Второе адресное пространство - это физическая память. Это просто ваша RAM - у вас есть ограниченное количество RAM. Также может быть аппаратное обеспечение с подключенными к памяти устройствами ввода-вывода, которые выглядят как ОЗУ, но на самом деле это какое-то аппаратное устройство, такое как карта PCI, или, возможно, память на видеокарте и т. Д.
Третий тип адреса - виртуальное адресное пространство. Если у вас меньше физической памяти (ОЗУ), чем требуется программам, операционная система может имитировать наличие большего объема ОЗУ, предоставляя программе иллюзию наличия большого объема ОЗУ, имея только часть этой фактически ОЗУ, а остальная часть - в «файле подкачки». Например, скажем, ваша машина имеет 2 МБ оперативной памяти. Скажем, на программу выделено 4МБ. Что произойдет, если операционная система зарезервирует 4 МБ адресного пространства. Операционная система будет пытаться сохранить самые последние / часто используемые части этих 4 МБ в реальном ОЗУ. Любые разделы, к которым не часто / недавно обращались, копируются в «файл подкачки». Теперь, если программа касается части этих 4 МБ, которые на самом деле не находятся в памяти, ЦП будет генерировать «сбой страницы». Операционная система найдет некоторую физическую память, к которой недавно не обращались, и "страницу в" этой странице. Возможно, ему придется записать содержимое этой страницы памяти в файл подкачки, прежде чем он сможет отобразить данные, к которым осуществляется доступ. Вот почему он называется файлом подкачки - обычно, когда он читает что-то из файла подкачки, он, вероятно, должен сначала что-то записать, эффективно обменяв что-то в памяти чем-то на диске.
Типичное аппаратное обеспечение MMU (блок управления памятью) отслеживает, к каким адресам обращаются (т.е. читают) и модифицируют (то есть пишут). Типичные реализации подкачки часто оставляют данные на диске, когда они выгружаются. Это позволяет ему «отбрасывать» страницу, если она не была изменена, избегая выписывания страницы при замене. Типичные операционные системы периодически сканируют таблицы страниц и сохраняют некую структуру данных, которая позволяет разумно и быстро выбирать, какой объем физической памяти не был изменен, и со временем собирает информацию о том, какие части памяти часто изменяются и какие части нет.
Типичные операционные системы часто аккуратно выводят страницы, которые не часто меняются (осторожно, потому что они не хотят генерировать слишком много дисковых операций ввода-вывода, которые мешали бы вашей реальной работе). Это позволяет мгновенно отбрасывать страницу, когда операции подкачки требуется память.
Типичные операционные системы будут пытаться использовать все «неиспользованное» пространство памяти для «кэширования» (сохранения копии) фрагментов файлов, к которым осуществляется доступ. Память в тысячи раз быстрее, чем диск, поэтому, если что-то часто читается, хранение в оперативной памяти происходит значительно быстрее. Как правило, реализация виртуальной памяти будет связана с этим «дисковым кешем» в качестве источника памяти, который можно быстро восстановить для операции подкачки.
Написание эффективного менеджера виртуальной памяти чрезвычайно сложно. Он должен динамически адаптироваться к меняющимся потребностям.
Типичные реализации виртуальной памяти чувствуют себя очень медленно. Когда машина начинает использовать гораздо больше памяти, чем у нее, общая производительность становится очень, очень плохой.