Re: [elmo-users] Alokacja pamięci.

[dave]

W dniu pon, 14 kwi 2003 18:16:02 +0200 rzyjontko napisał:
> Oto znane mi strategie alokowania pamięci:
>  - Dla każdego stringa, którego chcemy mieć kopię wywołujemy strdup
>    (który tak na prawdę wywołuje malloca, a potem kopiuje stringa).
>  - Mieć swój moduł alokujący pamięć (coś jak bytechunk w gnu libc).
>  - Pisać do pamięci dopóki się da i zadeklarować signalhandler dla
>    segfault, który zaalokuje następną porcję pamięci.

Po pierwsze, trzecia strategia z góry odpada, bo w linuksie możesz dostać
sigfault dopiero jakiś czas po przekroczeniu zakresu swojej pamięci.
Teoretycznie mógłbyś dbać o to, żeby było zdefiniowane MALLOC_CHECK=2 czy
jakoś tak, ale to chyba nie byłoby ładne.

Moja propozycja jest następująca: rozróżnijmy specjalny przypadek alokacji
pamięci, który charakteryzuje się tym, że przydzielamy wiele małych
fragmentów pamięci, których nie zwalniamy podczas działania programu, a
dopiero na końcu. Taką pamięć można by alokować inną funkcją niż xstrdup
(ystrdup?). Moduł, który by to realizował, trzymałby takie duże fragmenty
pamięci, w których trzymałby stringi jeden za drugim:

offset   : 0  1  2  3  4  5  6  7 8 9 ...
zawartość: a  l  a  \0 m  a  \0 (empty)
           ^
           |
  base-----+

a przy alokacji następnego fragmentu zwrócimy base + 7 czy jakoś tak 
(no i oczywiście skopiujemy tego stringa w odpowiednie miejsce). 

Jeśli następny alokowany string się nie mieści, to alokujemy następny duży
fragment itp. Taka strategia jest ok pod warunkiem, że rozmiary tego co
alokujemy są bardzo małe w porównaniu z rozmiarami bloków, bo inaczej
stracimy dużo śmieci na resztki, ale do tablicy hashującej powinno pasować.

Oczywiście takiej pamięci nie można poprzesuwać, więc nie możemy nic usuwać,
ale przecież problem mamy właśnie z taką pamięcią, której nie chcemy usuwać. 
Dopiero na końcu działania programu moduł odpowiedzialny za te sprawy
zwalnia wszystkie duże bloki.

Dzięki temu mamy mało zwalniania, mało fragmentacji itp.
No i oczywiście odraczamy sprawę alokacji pamięci na listy przy przyszłym
przechodzeniu ze skrzynki do skrzynki.

Otrzymujemy w ten sposób alternatywny sposób alokacji pamięci w szczególnych
przypadkach, którego możemy odtąd używać w całym programie. 

No i co wy na to?

-- 
Elmo: A MUA that sucks much less.