В чем смысл термина "арена" по отношению к памяти?

Я читаю текст в памяти как концепцию программирования. В одной из последующих глав автор широко использует слово "арена", но никогда не определяет его. Я искал технический смысл этого слова, но ничего не нашел. Вот несколько контекстов, в которых автор использует термин "арена":

"Следующий пример сериализации включает стратегию, называемую выделение памяти с определенной арены".

"... это полезно при работе с утечками памяти или при распределении с определенной арены".

"... если мы хотим освободить память, тогда мы освободим всей арены".

Автор использует термин более 100 раз в этой главе. Единственное связанное определение в глоссарии:

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

Единственный связанный с этим вопрос, который я нашел в SO, - Безопасность исключений на арене памяти 2, и не помогло. Может ли кто-нибудь определить "арену" для меня с учетом этих контекстов?

Ответ 1

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

char * arena = malloc(HUGE_NUMBER);

unsigned int current = 0;

void * my_malloc(size_t n) { current += n; return arena + current - n; }

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

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

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

Ответ 2

Я отвечу с этим как возможный ответ.

•Memory Arena (also known as break space)--the area where dynamic runtime memory is stored. The memory arena consists of the heap and unused memory. The heap is where all user-allocated memory is located. The heap grows up from a lower memory address to a higher memory address.

Я добавлю Синонимы Википедии: область, зона, зона, область или память.

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

Ответ 3

Подумайте об этом как о синониме "кучи". Обычно ваш процесс имеет только одну кучу/арену, и все распределение памяти происходит оттуда.

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

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

Ответ 4

От http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html:

Общая библиотека libc.so.x содержит компонент glibc и кучу код находится внутри него. Текущая реализация кучи использует несколько независимых подвалов, называемых аренами. На каждой арене есть свои мьютекс для защиты concurrency. Таким образом, если есть достаточные арены внутри процесса "куча" и механизм распределения потоков, куча доступа равномерно между ними, то потенциал для раздора для мьютексов должны быть минимальными. Оказывается, это хорошо работает для распределения. В malloc() выполняется тест, чтобы убедиться, что мьютекс для текущая целевая арена для текущего потока бесплатна (trylock). Если так то арена теперь заблокирована и распределение продолжается. Если мьютекс занят, тогда каждая оставшаяся арена проверяется поочередно и используется, если мьютекс не занят. В случае, если никакая арена не может быть заблокирована без блокировка, создается новая новая арена. Эта арена по определению еще не заблокированы, поэтому распределение теперь может продолжаться без блокировка. Наконец, идентификатор арены, используемой последним, является сохраняются в локальном хранилище потоков и впоследствии используются в качестве первого арену, чтобы попытаться, когда malloc() затем вызван этим потоком. Следовательно все вызовы malloc() будут выполняться без блокировки.

Вы также можете обратиться к этой ссылке:

http://www.codeproject.com/Articles/44850/Arena-Allocator-DTOR-and-Embedded-Preallocated-Buf