0. Sprava pameti

vetsina clanku o jazycich zacina popisem gramatiky. zacnu trosku netradicni modelem prace s pameti. hodne zasadnim rysem jazyka byva jak pracuje s pameti. sice se muze zdat, ze automaticka sprava pameti je domenou trendy jazyku jako java nebo c# a opravdovi muzi ji nepouzivaji, ale garbage collector je tu uz nekdy od konce 50. let, kdy byl vymyslen pro lisp.

0.1. Pocitani odkazu

jednoduchy model automaticke spravy pameti vychazi z myslenky, ze kazdy kousek pameti si u sebe drzi pocet odkazu (pocitadlo) na dany blok v pameti. a pokud je vytvoren odkaz na dane misto, zvysi se pocitadlo, pokud je odkaz zrusen pocitadlo se snizi. kdyz pocet odkazu spadne na 0, je pamet uvolnena. tento princip je pouzity treba ve smart pointrech.

krasna je teorie, oskliva je praxe. tento pristup ma velkou radu neduhu -- at uz je to rezije, kterou spotrebuje pocitadlo na sve ulozeni a operace scitani/odecitani taky nejaky cas zaberou. to nemluvim o tom, ze kdyz se jedna o vice vlaknovou aplikaci, je nutne, aby pocitadlo bylo chranene nejakym mutexem a to taky neco stoji. nejhorsi na tom je, ze pocitani odkazu nemusi vubec fungovat a muze delat osklive memory-leaky kvuli cyklickym odkazum. pocitani odkazu, i pres to, ze jde snadno pouzit a implementovat, se v praxi moc nepouziva, co vim, tak jej pouziva visual basic 6.0 a delphi na nektere typy datovych struktur.

0.2. Sber odpadku

bezne garbage collectory vychazi opet z myslenky, ze pamet se nebude pouzivat (a tudiz je uvolnitelna) v pripade, ze na ni nevede odkaz z nejakeho jineho kousku pameti. z teoretickeho pohledu je pamet rozdelena na kousky, ktere jsou provazany jako orientovany graf skladajici se z nekolika komponent. jenomze jak poznat, ktere casti jsou dostupne a ktere uz ne? neni to tezke. dostupne casti pameti jsou ty, ktere jsou odkazovany od nekud ze zasobniku nebo ze staticke promenne.

garbage collectoru je vicero druhu a jednotlive rysy se mezi sebou kombinuji. ale to je na uplne jiny clanek. napsat slusny garbage collector je docela veda. osvedcil se mne boehmuv konzervativni garbage collector, ktery jde velice snadno zaclenit do stavajicich c/c++ aplikaci. nekteri o nem rikaji, ze je pomaly, ale z open source collectoru je jeden z nejrychlejsi, podporuje slusnou radku platforem (vcetne amd64, coz je u rady collectoru problem) a ma vynikajici vykon ve vicevlaknovych aplikacich. nasel jsem par clanku, ze v ibm maji neco lepsiho... ale zdrojaky nejak nedali k dispozici. kdyby nekdo vedel o necem podobnem, dejte mne vedet.

pouzivani je proste, jak bulharska stripterka: staci linkovat proti knihovne "gc", pridat na zacatek kazdeho souboru "#include <gc/gc.h>" a pouzit nekterou funkci pro alokaci.

• GC_MALLOC(x) -- je obdobou bezneho mallocu, jedna se o nejobecnejsi funkci a pokud opravdu provedete v stavajici aplikaci nahradu mallocu za GC_MALLOC a odstraneni volani free(), mela by aplikace bezet
• GC_MALLOC_ATOMIC(x) -- alokuje pamet stejne jako predchozi funkce (potazmo makro), jenom s tim rozdilem ze dava collector napovedu, ze dana oblast neobsahuje odkaz do jine oblasti pameti (napr. pole doublu, intu, atp.), teoreticky by to melo zrychlit beh, ale osobne jsem moc velky rozdil nevidel

pokud aplikace ma bezet ve vicevlaknovem prostredi je nutne v souborech pouzivajici neco z knihovny pthread, pred inkluzi gc.h deklarovat makro GC_THREADS a collector nektere funkce obali svymi.

co je ale hezka vec, boehmuv kolektor se umi optimalizovat, aby kazde vlakno si alokovalo data zvlast a nemuselo dochazet k zamykani. staci pouzivat funkci GC_local_alloc(x), popr. deklarovat makro GC_REDIRECT_TO_LOCAL a to prevede vsechny volani GC_MALLOC na "optimalizovane". ma to ale jednu neprijemnou vlastnost. collector si uklada informace pomoci pthread_set_specfic, takze pokud je funkce volajici GC_local_alloc zavolana primo z procesu a ne z vlakna, zacne se chovat nepredvidatelne (teda segfaultuje). ale to jde resit, ze se v procesu spusti samostatne vlakno a predaji se mu jenom argumenty aplikace. (no jo, thready jsou v unixu cizorody element a prace s nimi neni tak komfortni jako treba ve windows)

pro vetsi nahled do problematiky garbage collectoru muzu doporucit stranky pana boehma, ktery vyvraci nektere myty a pak velice pekne pocteni http://www.sidhe.org/~dan/blog/archives/000200.html, kde jsou collectory popsane mnohem srozumitelneji nez ode me. 

Vytvořil(a) deda.jabko v 03. 03. 2007, 11:24