Vlákno názorů k článku Minimalistické překladače jazyka C: tcc a Chibicc od luky - Je otazka, jestli by garbage collector mel byt...

Je otazka, jestli by garbage collector mel byt soucasti jazyka a nebo ne. Spousta bezne funkcionality take neni definovana primo jazykem, ale treba v POSIXu. Nekolik takto implementovanych GC je pro C k dispozici, nejznamejsi je boehmgc (bdwgc), ktery vyuziva treba Inkscape, PyPy nebo Unity.

tyjo tezko rict. u jazyku, ktere moc neresi, kde se objekty vytvari, to asi jde. U cecka je to horsi, to uz ma ve specce zbytecne podrobnosti AFAIK

Tak zrovna ten boehmgc muze fungovat i v modu, kdy kompletne nahradi malloc, takze se pak nemusite starat ani o uvolnovani pameti naalokovane knihovnami, ktere nebyly pro alokator napsany. Samozrejme jen za predpokladu, ze k uvolneni vsech zdroju neni potreba provest jeste nejakou dalsi operaci (treba zavolat close()).

no jasne, ale porad se do toho bude plest omezeni jazyka. Prikad, alokace v ramci funkce v cecku na zasobnikovem ramci a vraceni ukazatele - to je proste spatne, kdezto v jazycich typu Java nebo Go se to neresi (v Jave proto, ze je vsechno reference na heap nebo primitivni hodnota, v Go proto, ze to kompilator odhali a neda tu oblast na zasobnik, ale na heap).

to me na zacatku v go leknulo, ze funkce vracela treba:

return &NejakyObjekt;

pak jsem zjistil, ze go samo urci, ze to patri na heap a vrati spravny ukazatel.

Problém je, že Boehm GC neví, co je pointer a co není. Takže se může stát, že uvolní data, ke kterým se jde ještě dostat, nebo naopak data, která měl uvolnit neuvolní třeba jen proto, že někde jinde je int, co má hodnotu shodnou s adresou.

aha, to je tedy zajime chovani s tim intem. Musim se na to podivat, to bude asi hodne velky hack ;)

kdyz je dost pameti tak se mi libi naalokovat si nejakou pametovou oblast, v ni si delat male alokace a neresit memory leaky a jen hlidat vymazani te oblasti.

To už fungovalo někdy v Pascalu 7 - stačilo označit označit počátek hromady (Heap) a na konci ho vrátit zpět. Je trochu (hodně) nepotěšující, že se správa paměti musí řešit ještě dneska.

To je tím, že správa paměti (a zdrojů celkově) je hodně složitý problém. A strategie, co dává smysl v nějakém kontextu, může být jinde mizerná nebo úplně nepoužitelná.

Tohle je docela dobrý a rychlý způsob u webových serverů, kde se taková oblast zřídí per request. Nebo programů, které zpracovávají eventy, tam se alokuje per event a po zpracování eventu se celá oblast uvolní. Případně her, kde se to může dělat per frame.

Nebo různých parserů, atd... je to naprosto běžná věc.

Takhle funguje management paměti v Postgresu. Je to nadstavba nad malloc - která vytváří hiearchii tzv paměťových kontextů. palloc alokuje paměť z vybraného nebo aktuálního kontextu, pfree může paměť uvolňovat. Paměťové kontexty mají definovanou životnost - transakce, query, výpočet řádku, výpočet výrazu. Na začátku je náročnější na to zvyknout - musíte vracet data ve správném kontextu, pak to funguje jak víno.

Hlavně je to relativně jednoduchý přímočarý mechanismus bez jakýkoliv jednoduchých nebo složitých (chytrých) heuristik. Jednoduché, ale chytré a roky s tím nejsou žádné problémy.