Что означает термин «арена» применительно к памяти?

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

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

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

«... если мы хотим освободить память, мы освободим всю арену ».

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

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

Может ли кто-нибудь определить для меня арену с учетом этих контекстов?

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

char * arena = malloc(HUGE_NUMBER);

unsigned int current = 0;

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

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

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

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

Я выберу этот как возможный ответ.

•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()могут быть дорогостоящими (каждое выделение памяти имеет стоимость производительности: время, необходимое для выделения памяти в логическом адресном пространстве вашей программы, и время, необходимое для назначения этого адресного пространства физической памяти) где, как если бы вы знали парк мячей, вы можете получить большой кусок памяти, а затем передать его своим переменным как / как вам это нужно.

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

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

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

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

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

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

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