A FreeBSD-ből ismert jemalloc lesz a Firefox új memória allokátora

Mozilla

Úgy hírlik, hogy a FreeBSD-s, Jason Evans-féle jemalloc lesz Mozilla Firefox 3 új memória allokátora. A váltásra azért kerül sor, mert a fejlesztők szerint a jemalloc jobb az összes eddigi, a Mozilla által használt allokátornál. Nem csak gyorsabb, de kevésbé okoz fragmentációt a memóriában, így hosszabb böngészőhasználat esetén is jelentősen kisebb memóriahasználatra lehet majd számítani a jemalloc-ot használó Firefox build-ektől. Bővebben itt.

( vomberg | 2008. 02. 22., p – 21:20 )

Nem egy hülye ötlet, mert 4-5 nap folyamatos használat után fejreáll a FF.

A kezdtektől fogva azt csinálja (még a Mozilla is), hogy 4-5 nap folyamatos használat után a linkre kattintást névtelen, menü-eszköztár nélküli új ablakban kezdi feldobálni, az ablakok közt nem lehet váltani, szóval összeomlik. A memória ilyenkor jellemzően 2-300 MB-nál tart, szinte ok nélkül.

Azért gondolom, hogy az allokátor memóriafragmentálási gondja lehet mögötte, mert ősi a probléma, átível minden verzión, javításon, bármin, és nem igazán az időhöz hanem a használatban töltött időhöz kötődik.

Érdekes, nekem erről amit leírtál az jut eszembe, hogy ez nem a memória-töredezettség miatt van - lévén egy applikációnak, ha malloc/free -t korrekten használ, tök mindegy, hogy hol és mi módon van az a visszakapott memóriaszelet. Ellenben ez "egyszerű" programszintű memóriakezelési hiba. A memória-töredezettség nem összeomlást kellene okozzon, hanem maximum lassulást. Esetleg azt, hogy az allokátor már nem tud (esetleg nem annyi) szabad memóriát visszaadni, amennyit a program kér - de ezt hibastátusszal szokták jelezni, amit a programnak úgyszintén le kéne kezelnie.

( mrev | 2008. 02. 23., szo – 16:29 )

Biztos nagyszerű a jemalloc, de szerintem szemétgyűjtés kellene (libgc).
--
CCC3

Amennyire én megértettem az ügyet: ez nem oldaná meg a teljes problémát.

Nemcsak az a baj, hogy felszabadítatlan területek "ragadnak benn", hanem hogy a mostani malloc-cal a következő történik. Lefoglalunk egy vagon kis memóriadarabot, a felét felszabadítjuk, aztán megint egy keveset lefoglalunk és egy adagot felszabadítunk, .... és a végén a foglalt területek sok is darabban a memória minden helyén fellelhetők lesznek, kicsi helyet hagyva maguk között. Elvileg sok szabad hely van, de ezek kihasználhatatlan kis darabokban találhatók meg. És egy 10 bájtos foglalt terület is foglattá tesz egy több kb-os memória-lapot a többi processz elől, így ha sok kis darabra szakadva található a Firefox memóriafoglalása, a szükséges terület sokszorosát happolja el a többi processz elől. Még akkor is, ha minden, már nem használt memóriarészre meghívtuk a free-t.

A jemalloc állítólag úgy foglal területet, hogy ez a jelenség (fragmentálódás) sokkal kisebb mértékben következik be.

( ProTech | 2008. 02. 24., v – 11:31 )

Ezt a hirt nem nagyon ertem. A malloc nem egy rendszerhivas? Szoval a kernelben van megvalositva. Nem igazan ertem, hogy hogy tudjak felulutni a kernel memoria allocatorat a sajatjukkal. Az ok, hogy FreeBSD alatt ezt hasznaljak, de Linux alatt mit? Max ugy tudom elkepzelni, hogy lefoglalnak egy nagyobb memoriaszeletet a kerneltol, es utanna abbol osztogat maganak. Valaki homalyositson mar fel, eleg reg programoztam utoljara c-ben.

> A malloc nem egy rendszerhivas?

Eltallatad, nem. A malloc(3) egy C-konyvtari fv, amely hasznal valamilyen rendszerhivas(oka)t. Hagyomanyos UNIX-rendszereken brk(2) / sbrk(2) neven volt a megfelelo rendszerhivas, de azota eleg sok viz lefolyt mar a Dunan. FreeBSD man-ban ez talalhato:

DESCRIPTION
The brk() and sbrk() functions are legacy interfaces from before the
advent of modern virtual memory management.