Jakie jest znaczenie terminu arena w odniesieniu do pamięci?

Czytam książkę o pamięci jako koncepcji programowania. W jednym z późniejszych rozdziałów autor intensywnie używa słowa arena , ale nigdy go nie definiuje. Szukałem znaczenia tego słowa i jego związku z pamięcią, ale nic nie znalazłem. Oto kilka kontekstów, w których autor używa terminu:

„Następny przykład serializacji obejmuje strategię zwaną alokacją pamięci z określonej areny ”.

„… jest to przydatne w przypadku wycieków pamięci lub przy przydzielaniu z określonej areny ”.

„... jeśli chcemy zwolnić pamięć, zwolnimy całą arenę ”.

W jednym rozdziale autorka używa tego terminu ponad 100 razy. Jedyna definicja w glosariuszu to:

alokacja z areny - technika przydzielania najpierw areny, a następnie zarządzania alokacją / cofnięciem alokacji w obrębie areny przez sam program (a nie przez menedżera pamięci procesu); używany do zagęszczania i serializacji złożonych struktur danych i obiektów lub do zarządzania pamięcią w systemach krytycznych dla bezpieczeństwa i / lub odpornych na błędy.

Czy ktoś może zdefiniować dla mnie arenę w tych kontekstach?

Arena to po prostu duży, ciągły fragment pamięci, który można alokować raz, a następnie używać do ręcznego zarządzania pamięcią, rozdając części tej pamięci. Na przykład:

char * arena = malloc(HUGE_NUMBER);

unsigned int current = 0;

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

Chodzi o to, że masz pełną kontrolę nad tym, jak działa alokacja pamięci. Jedyną rzeczą poza twoją kontrolą jest pojedyncze wywołanie biblioteki dla początkowej alokacji.

Jednym z popularnych przypadków użycia jest sytuacja, w której każda arena jest używana tylko do przydzielania bloków pamięci o jednym, stałym rozmiarze. W takim przypadku możesz napisać bardzo wydajne algorytmy odzyskiwania. Innym przypadkiem użycia jest posiadanie jednej areny na „zadanie”, a kiedy skończysz z zadaniem, możesz zwolnić całą arenę za jednym razem i nie musisz martwić się o śledzenie indywidualnych zwolnień.

Każda z tych technik jest bardzo wyspecjalizowana i ogólnie jest przydatna tylko wtedy, gdy wiesz dokładnie, co robisz i dlaczego normalny podział bibliotek nie jest wystarczająco dobry. Zauważ, że dobry alokator pamięci już sam wykona wiele magii i potrzebujesz przyzwoitej ilości dowodów, że to nie jest wystarczająco dobre, zanim zaczniesz samodzielnie obsługiwać pamięć.

Pójdę z tym jako możliwą odpowiedzią.

•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.

Dodam synonimy Wikipedii : region, strefa, arena, obszar lub kontekst pamięci.

Zasadniczo jest to pamięć, którą otrzymujesz z systemu operacyjnego i dzielisz, a następnie można ją uwolnić od razu. Zaletą tego jest to, że powtarzające się małe wywołania malloc()mogą być kosztowne (każda alokacja pamięci wiąże się z kosztem wydajności: czas potrzebny na przydzielenie pamięci w logicznej przestrzeni adresowej programu i czas potrzebny na przypisanie tej przestrzeni adresowej do pamięci fizycznej) gdzie jakbyś znał park z piłkami, możesz zdobyć dużą porcję pamięci, a następnie rozdać ją swoim zmiennym tak, jak tego potrzebujesz.

Potraktuj to jako synonim „sterty”. Zwykle twój proces ma tylko jedną stertę / arenę i stamtąd odbywa się cała alokacja pamięci.

Ale czasami masz sytuację, w której chciałbyś zgrupować razem serię alokacji (np. W celu wykonania, aby uniknąć fragmentacji itp.). W takim przypadku lepiej jest przydzielić nową stertę / arenę, a następnie dla dowolnej alokacji możesz zdecydować, z której sterty przydzielić.

Na przykład możesz mieć system cząstek, w którym wiele obiektów tego samego rozmiaru jest często przydzielanych i zwalnianych. Aby uniknąć fragmentacji pamięci, możesz przydzielić każdą cząstkę ze sterty, która jest używana tylko dla tych cząstek, a wszystkie inne alokacje pochodziłyby ze sterty domyślnej.

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

Biblioteka współdzielona libc.so.x zawiera komponent glibc, w którym znajduje się kod sterty. Bieżąca implementacja sterty wykorzystuje wiele niezależnych stert podrzędnych zwanych arenami. Każda arena ma swój własny mutex do ochrony współbieżności. Tak więc, jeśli istnieje wystarczająca liczba aren w stercie procesu i mechanizm równomiernego rozprowadzania dostępu do sterty wątków między nimi, wówczas potencjał rywalizacji o muteksy powinien być minimalny. Okazuje się, że działa to dobrze w przypadku alokacji. W malloc () wykonywany jest test, aby sprawdzić, czy mutex dla bieżącej areny docelowej dla bieżącego wątku jest wolny (trylock). Jeśli tak, to arena jest teraz zablokowana i przydział jest kontynuowany. Jeśli mutex jest zajęty, każda pozostała arena jest sprawdzana po kolei i używana, jeśli mutex nie jest zajęty. W przypadku, gdy żadna arena nie może zostać zablokowana bez blokady, tworzona jest nowa, nowa arena. Ta arena z definicji nie jest już zablokowana, więc alokacja może teraz przebiegać bez blokowania. Wreszcie, identyfikator areny ostatnio używanej przez wątek jest zachowywany w lokalnej pamięci wątku, a następnie używany jako pierwsza arena do wypróbowania, gdy funkcja malloc () jest następnie wywoływana przez ten wątek. Dlatego wszystkie wywołania malloc () będą kontynuowane bez blokowania.

Możesz również skorzystać z tego linku:

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