управление памятью mips

Question

как вы вручную управляете кучей в сборке mips, в частности симулятором SPIM?

куча, которую я нашел, начинается с 0x10040000 при использовании системного вызова sbrk, например,

li $t0, 1

li $s0, 9

syscall

sw $t0, ($s0) # 1 located at 0x10040000

итак, вызов в sbrk НЕ гарантирует, что вы вернете следующий свободный слот памяти?например, если я вызвал sbrk для одного 4-байтового пространства, SPIM мог бы выделить адреса: 0x10040000-0x10040003.однако второй вызов для другого 4-байтового пространства может быть не связан с предыдущим 4-байтовым распределением?Таким образом, структура данных требуется для отслеживания, какие слоты памяти были выделены?наконец, пытаются ли менеджеры памяти уменьшить количество обращений к sbrk путем определения свободного пространства между адресами, которые отслеживаются конкретной структурой данных?

Answer 1

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

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

(Обратите внимание, в вашем случае я считаю, что симулятор SPIM берет целое число для увеличения указателя, поэтому неявно вся память является непрерывной, и я думаю, что разрыв всегда увеличивается?)

API "malloc", который обычно построен на sbrk, предоставляет больше, чем просто непрерывный, растущий объем памяти. Хорошая библиотека malloc обычно позволяет пометить область памяти как «свободную» (поэтому ее можно использовать для удовлетворения последующего вызова malloc). Обратите внимание, что ОС обычно не знает об этом "бесплатно". Malloc отслеживает, свободна память или нет. В общем случае malloc не может вернуть эту произвольную область кучи ОС, поскольку куча представляет собой единую непрерывную область с точки зрения ОС.

Реальные реализации malloc должны иметь дело с несоответствием между запросами на выделение и размером страницы (обычный sbrk возвращает только кратные значения для выровненных по размеру страниц). В вашем случае с симулятором такой проблемы нет, потому что sbrk мелкозернистый.

Обратите внимание, что отслеживание того, какая память используется или нет, требует памяти, поэтому у malloc есть некоторые накладные расходы. Некоторые реализации предназначены для хранения большей части этой бухгалтерии в «свободной» памяти (уменьшая очевидную стоимость для клиента). Существует множество других стратегий для сопоставления malloc с sbrk .... (В вашем случае отображение malloc на sbrk и освобождение no-op будет «работать», если вы не выделяете слишком много памяти ...)

Вот краткий обзор того, как malloc и sbrk связаны, что привлекает некоторое искусство ASCII. У меня нет терпения транскрибировать: http://web.eecs.utk.edu/~huangj/cs360/360/notes/Malloc1/lecture.html