Яке значення терміна арена стосовно пам’яті?

Я читаю книгу про пам'ять як концепцію програмування. В одному з пізніших розділів автор широко використовує слово арена , але ніколи не визначає його. Я шукав значення цього слова та його відношення до пам’яті, і нічого не знайшов. Ось кілька контекстів, у яких автор використовує термін:

"Наступний приклад серіалізації включає стратегію, яку називають розподілом пам'яті з певної сфери ."

"... це корисно при роботі з витоками пам'яті або при виділенні з певної арени ."

"... якщо ми хочемо розмістити пам'ять, тоді ми розберемо всю арену ".

Автор використовує в одній главі термін понад 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 () проводиться тест, щоб перевірити, чи вільна mutex для поточної цільової арени для поточного потоку (трилок). Якщо так, то арена тепер заблокована, і розподіл триває. Якщо мютекс зайнятий, то по черзі пробується будь-яка залишилася арена та використовується, якщо мютекс не зайнятий. У випадку, якщо жодна арена не може бути заблокована без блокування, створюється нова свіжа арена. Ця арена за визначенням ще не заблокована, тому виділення тепер може тривати без блокування. Нарешті, ідентифікатор арени, який останній використовується потоком, зберігається в локальному сховищі потоку, а згодом використовується як перша арена, щоб спробувати, коли наступний потік викликається malloc (). Тому всі дзвінки на malloc () будуть протікати без блокування.

Ви також можете посилатися на це посилання:

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