Каково значение термина Арена по отношению к памяти?
Я читаю книгу о памяти как концепции программирования. В одной из последующих глав автор широко использует слово Арена, но не определяет его. Я искал значение этого слова и его связь с памятью, но ничего не нашел. Вот несколько контекстов, в которых автор использует термин:
"следующий пример сериализации включает в себя стратегию под названием выделение памяти из определенного Арена."
"...это полезно при работе с утечками памяти или при выделении от конкретного Арена."
"...если мы хотим освободить память, то мы освободим весь Арена."
автор использует термин более 100 раз в одной главе. Единственное определение в глоссарии:
выделение из арены - техника выделения арены сначала, а затем управление распределение / освобождение арены по программе сам (а не с помощью диспетчера памяти процессов); используется для сжатие и сериализация сложных структур данных и объектов, или для управления памятью в критических для безопасности и /или отказоустойчивых системах системный.
может ли кто-нибудь определить Арена для меня учитывая эти контексты?
4 ответа:
Арена-это просто большой непрерывный кусок памяти, который вы выделили один раз, а затем использовать для управления памятью вручную, раздавая части этой памяти. Например:
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.
Я добавить Википедии!--4-->: регион, зона, Арена, область или контекст памяти.
в основном это память, которую вы получаете от ОС, и делите, а затем можете освободить все сразу. Преимуществом этого является то, что повторяются небольшие вызовы
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