kdyz uz se autor pousti do podobneho tematu, nemel by rozhodne zapominat na 'odolnost' heapy jako takove, to jest odolnost proti prepisum marku/velikosti, odolnost proti leakum a tak dale. Fakt, ze Dag Lemovo heapa (std pouzivana v glibc a zminovana autorem) nema defacto zadne podobne funknce a tise veskere 'chyby' ignoruje nas napr. donutila napsat si vlastni (dokonce jsme si psal s Dagem :) Jasne, jsou ruzne 'nadstavby', ale jsou to vetsinu zaplaty nez systemove reseni....
Osobne si myslim, ze odolnost heapy vuci 'chybam' je velice dulezita cast a nemala byt zcela ingorovana.
Popsana 'fragmentace' je take dost silne zkreslena. Spojeni vice free bloku do jednoho samo o sobe nic neresi, specialne v c++. Jsou tu daleko horsi problemy. U resizovani bloku predvidani (at uz se jedna o velke nebo male bloky), pridelovani V pameti bez prideleni fyzicke a rada dalsich metod.
Nu, kdyz uz autor zabrousil do podobneho tematu, nemel dle mne opomenou dost dulezite veci :)
O dalsim dile uvazuju, ale ten bude spis zamereny na alokaci pameti v jadre. Ja tento clanek napsal pote, co jsem nekolik dni zkoumal zdrojak mallocu a hledal ruzne clanky na googlu. Jako cil jsem si dal popsat jak funguje stavajici malloc.
Rozhodne ale dik za pripominky, urcite se na to jeste kouknu a jestli me to chytne, urcite pouvazuju o pokracovani na toto tema.
Kdyby v tom článku bylo všechno co popisujete, byl by třikrát tak dlouhý. Takže se to může objevit v pokračování, ale podle mě byl tenhle článek přimeřený.
BTW, proč je v C++ spojování bloků k ničemu? (Přiznávám se, že o implementaci new a delete v GCC nic nevím.)
Vznikne 'fragment'... Klasicke (typicky dedeni a vytvareni child objektu - knihovny MFC, GTK a dalsi) se vyznacuji prave obrovskym mnozstvim 'malych' alokaci (odtud i jejich pametova narocnost, rezie klasicke heapy je OBROVSKA).
Takze ac 'mame' volnou pamet 3*16 bajtu, nejsme schopni ji nalokovat. Takhle to smozrejmne vypada trivialne, ale tech alokaci jsou stovky tisic/miliony. Dag mel na strankach hezke grafy, podivam se jesli je tam ma jeste... Ma :)
Na nekterych grafech je pekne videt o cem mluvim a navic je se da podivat i na velikosti alokacnich bloku. Autor mohl techno grafu zneuzit :)
I proto se vyplati (a dela se to) rozdelit heapu ne na ~2, ale na ~3 casti. Jedna na male bloky, jena na normlani (rekneme ~32bajtu az ~stovky kil) a potom velke bloky (povetsine se nechava na kernelu).
Ad poznamka o velikosti (3x tak vetsi clanek).... Neni prece duvod to rozepisovat do detajlu, ale kdyz uz se autor pustil do tohoto tematu (a ma pravdu v tom, ze hodne lidu o tom nema ani potuchy), tak myslim, ze odstavec venovany na tema robusnosti a pod. neni od veci.
A hlavne, neuskodil by trochu vice kriticky pohled na Dagovo malloc (srovnani s jinymi open source nahrazkamy - je jich dost.
Ad child objekty: zjišťoval někdo, jak velký má vliv na Gtk+ to, že glib si uchovává pooly volných objektů (teda žádných objektů, prostě svých datových typů, jako GSList, GList, ...), takže při g_blabla_free() se akorát přihodí do poolu a při g_blabla_new() se zase akorát zrecykluje? Nějaký pěkný graf? ;-)
Ad kritický pohled: asi jo. Ale těžiště článku je v srozumitelném popisu fungování mallocu glibc, a to bych řekl, že se podařilo.
