Смежные блоки памяти и ВМ - PullRequest
1 голос
/ 06 июля 2011

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

Ответы [ 3 ]

2 голосов
/ 06 июля 2011

Является ли что-то, что перекрывает границу страницы, на самом деле смежным в физической памяти, с современными обработчиками памяти никогда точно не узнается. Логика склеивания памяти, по существу, обрабатывает все адресуемые страницы памяти как неупорядоченный набор, а порядок, по существу, связан с процессом; нет никакой гарантии, что для разных процессов, которым в конечном итоге будут присвоены одни и те же две страницы физической памяти (в разные моменты времени), что выраженные отношения между этими физическими страницами будут одинаковыми. Фактически, существует слой трансляции между процессором и памятью, который обрабатывает эти вещи.

2 голосов
/ 06 июля 2011

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

1 голос
/ 29 октября 2013

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

Компилятор (или тот, кто пишет код на ассемблере) может обрабатывать адреса программы как начинающиеся с 0 и повышающиеся до самого большого адреса, необходимого для этой конкретной программы. Затем операционная система создает таблицу страниц для каждого процесса и использует эту таблицу для частичного декодирования физического адреса для каждой ячейки виртуальной памяти. ОС обрабатывает адрес в программе как две отдельные части: адрес страницы и смещение на этой странице. Затем MMU преобразует адрес страницы в адрес физического кадра. Обратите внимание, что «кадр» физической памяти аналогичен концептуальной «странице» с точки зрения ОС; эти два имеют одинаковый размер (например, 4096 байт).

Поскольку физическая память разделена на фреймы одинакового размера, а размер страницы совпадает с размером фрейма, вы можете узнать, какая часть вашего виртуального адреса используется в качестве местоположения страницы и сколько смещений в эту страницу. Например, если ваша ОС «выделяет» 4 гигабайта каждому процессу (как в случае с Linux), а размер вашей страницы / фрейма составляет 4096 байт, вы можете знать, что 20 бит (4 294 967 296 байт / 4096 байт = 2 ^ 20 = 1 048 576 страниц / адресов страниц) 32-битного адреса используются в качестве адреса страницы, который затем преобразуется MMU в физический адрес кадра, а оставшиеся 12 бит используются в качестве смещения для определения местоположения начала адреса с начала страницы / фрейма.

VM (темп пользователя) адрес -> страница + смещение (OS) -> фрейм + смещение (MMU) = физический адрес

...