Dotaz: Uvolňování paměti v C++

[Jan Zahornadsky]

Pěkný den všem,

chtěl bych se zeptat, jak funguje ubolňování paměti v Linuxu v C/C++. Mám totiž jednu stromovou strukturu (opravdu hodně velkou), kde je každý uzel třída, delete-ují se rekurzivně. Valgrind nehlásí žádný memory leak. Ale když třeba na konec programu přidám sleep(30) a kouknu na top, stále vidím, že můj program zabírá přes 270MB. Ale například miniaturní demo

        const int HODNE = 10000;
        char **pole = new char*[HODNE];
        for (int i = 0; i < HODNE; i++)
        {
                pole[i] = new char[HODNE];
//                for (int j = 0; j < HODNE; j++) pole[i][j] = 0;
        }
        sleep(30);
        for (int i = 0; i < HODNE; i++) delete [] pole[i];
        delete [] pole;
        sleep(30);

si ani tu paměť nealokuje. Pokud však odkomentuji jeden z těch řádků, tak až pak mi kernel tu paměť opravdu přidělí. To je docela zajímavá myšlenka, dokáže to skutečně dát programu jen tu paměť co kdy použije. Co mě ale mnohem víc zaráží, je, když sleduji tento program v topu, tak jeho paměť je uvolněna de facto hned po delete.

Neví někdo, jaký algoritmus používá jádro pro určení, kdy paměť uvolní a kdy alokuje (i link by byl supr, asi hledám blbě )? Nebo je možné, že valgrindu uniklo těch 270MB, co můj program má stále přidělených těsně před koncem, po všech deletech?

Předem díky!

Odpovědi

[#Tom]

Jádro paměť přiděluje i tehdy, když jí není dost, spoléhá se na to, že jí nebude tolik potřeba. (Na to je volba sysctl vm.overcommit_memory). Přiděluje se ale asi až po prvním použití (jako v tom cyklu), kdy se po uvolnění v programu uvolní doopravdy, to asi také závisí na situaci – kdyby paměť docházela, jádro by ji asi uvolnilo dřív.

[Jan Zahornadsky]

To uvolňování mi právě nejde do hlavy, 270MB neuvolní hned, to čeká až na konec programu, kdežto těch cca 100MB co udělá uvedené demo se uvolní hned. Ještě zkusím nějaké demo s třídami, ale nevím, proč by se na to mělo pohlížet odlišně.

[Jan Zahornadsky]

Tak teď už nevím. Toto demíčko:

        CString ***tridy = new CString**[HODNE];
        for (int i = 0; i < HODNE; i++)
        {
                tridy[i] = new CString*[MENE];
                for (int j = 0; j < MENE; j++)
                {
                        tridy[i][j] = new CString();
                        tridy[i][j]->Append("kraviny v pameti");
                }
        }

        printf("Pamet v tridach alokovana.\n");
        sleep(30);

        for (int i = 0; i < HODNE; i++)
        {
                for (int j = 0; j < MENE; j++) delete tridy[i][j];
                delete [] tridy[i];
        }
        delete [] tridy;

        printf("Pamet v tridach uvolnena.\n");
        sleep(30);

(CString je třída, která uchovává řetězec v dynamicky alokovaném poli)

Funguje, jak bych čekal (tj. po posledním sleepu zabírá program třicet vteřin minimum paměti). Je možné, že mi valgrind u mého programu něco tají? (napsal ale "No memory leaks possible")

Pokud by to někoho zajímalo, tak se jedná o třídu implementující Patricii, ten testovací program do ní vloží postupně každý řádek souboru, pak postupně z ní každý záznam odstraní a pak nechá ještě zapůsobit destruktor (který zavolá rekurzivně destruktor na potomky uzlu -- žádni by ale zůstat neměli).

[Jan Zahornadsky]

Pokračuji ve výzkumu... Zdá se, že Linux i Solaris na uvolnění té paměti nespěchají, kdežto Windows ano (co je ještě hezčí je, že tatáž struktura si sní cca 277MB na Linux 64bit, 151MB na Solarisu 32bit a konečně cca 250MB na Windows 32bit).

[Martin]

Tiež by ma zaujímalo ako je to s uvoľňovaním pameti, pretože ma toto správanie dosť prekvapilo. A k tomu príkladu. Aké si použil možnosti kompilátora? -0s || -O2 ???

[wake]

no, a co se takhle podivat do libc, jak je napsany malloc, calloc, realloc, free, new a delete? mezi volanim malloc[libc] a volanim brk[kernel] je spousta kodu.

[pzad]

libc alokuje pamat od jadra vo velkych blokoch a potom ju deli na mesie kusky. Vratit jadru ju moze az ked je volny cely blok. Pri pridelovani sa pamat fragmentuje, takze sa moze stat, ze sa tam vzdy nieco najde, co nie je este volne.

[Jan Zahornadsky]

To zní pravděpodobně. Je nějaká možnost, jak tuto fragmentaci odhalit a optimalizovat to? Protože se mi nelíbí, že pokud bych tuto část použil v předzpracování, aby kvůli možná jediné proměnné nešťastně v main() se neuvolnilo řádově desítky až stovky MB...

[Michal Kubeček]

Jedna možnost, když už se bavíme o C++, je napsat si pro tyto účely vlastní implementaci operátorů new, new[], delete a delete[]. Otázkou samozřejmě je, zda se vám do toho bude chtít.

[Jan Zahornadsky]

To ale bude pak nutně platform-specific, ne? :-/

[Kyosuke]

Nebude, pokud budete používat ve svých alokátorech přenositelné konstrukce. Nebo mě aspoň nic zádrhelovitého nenapadá. Možná v Boostu by se daly vyštrachat nějaké příklady ma tohle téma.

[Michal Kubeček]

Ne nutně, podle manuálové stránky by syscall mmap() měl odpovídat POSIXu, takže přinejmenším na POSIXových systémech by to přenositelné být mělo. A i kdybyste to chtěl portovat třeba na win32, mělo by stačit udělat variantní tu část, která získává od systému kus paměti. Rozparcelování těch bloků už si uděláte univerzálně, v podstatě stačí dát pozor na zarovnávání toho, co vracíte.

[Jan Zahornadsky]

Co se optimalizací týče, tak jak v Solarisu, tak ve VS (2005 verze, nevím, jestli se to nějak výrazně mění) jsem ponechal standardní nastavení (tj. bez jakýchkoli flagů kompilátoru). V linuxu jsem zkoušel různé nastavení, jak bez optimalizace, tak O2, Os, O3, ale spotřeba paměti se nezměnila.

[Michal Marek (twofish)]

Však to je spíš věc glibc, jestli se rozhodne volnou pamět skutečně uvolnit nebo ne.

[Jirka]

Alokace a uvolnovani dynamicke pameti zavisi na alokatoru (implementaci mallocu a spol.). Malloc je v linuxu implementovan volanim brk(), ktere pouze posunuje hranici heapu. Pri uvolneni pameti se blok oznaci jako volny, ale nevrati se uz zpet operacnimu systemu (hranice heapu se zpet uz neposune). Posunuti heapu (tj. vraceni pameti OS) lze vynutit pomoci malloc_trim, coz ovsem neni prenositelne.

Jinak jeste existuje prah velokosti alokovaneho bloku. Pokud se alokuje vice pameti nez je tento prah, provadi se prideleni pameti volanim mmap(), tj. mapovanim stranek. Pokud se takovato pamet uvolni, je skutesne vracena zpet OS. Tento prah lze nastavovat, napr. funkci mallopt() nebo i promennou prostredi MALLOC_MMAP_THRESHOLD_. Jaka je defaultni hodnota si nejsem jisty.

Pro vypis alokovanych bloku je velice uzitecna funkce mallinfo. viz /usr/include/malloc.h.

[Michal Marek (twofish)]

Wow, zase jsem se něco přiučil :)

[Michal Kubeček]

Pokud to nebylo myšleno jako ironie, doporučil bych článek na Linux Journal nebo pojednání u IBM.

[Michal Marek (twofish)]

Ne, to skutečně nebyla ironie.

[Michal Kubeček]

OK, jen jsem si nebyl jistý, jak mám chápat ten smajlík.