Az előző rész tartalmából

A Firefox 4 megjelenésével felerősödtek azok a kritikák, amelyek a böngésző memóriaéhségére panaszkodnak. Nem csoda, a Firefox 4 hosszas fejlesztése nyomán számos új funkció került a programba, amelyek önmagában is méretnövekedést okoznának. De úgy tűnik ennél azért többről van szó. A Firefox 4 ugyanis nem szabadítja fel kellő hatékonysággal a memóriát – és ez bizony elhízásra hajlamosít.
Mint az köztudott, a Mozilla termékek apraja és nagyja a felhasználói felület meghatározására a XUL leírónyelvet használja. Ennek fontos eleme, hogy a megvalósítás alappillére a JavaScript nyelv. A JavaScript feldolgozása az évek folyamán sokat gyorsult a SpiderMonkey C és C++ nyelven implementált JavaScript motorban. Ez elsősorban a TraceMonkey és a JägerMonkey JIT (Just-in-Time) fordítók megjelenésének köszönhető. A jövő pedig az IonMonkey fordító, de ennek a témának a kifejtése egy másik cikkre vár.

A Firefox számos újdonsága között megbújt az a tény, hogy a Firefox négyes verziójában a JavaScript memóriakezelését alaposán megreformálták. Dr. Andreas Gal hosszú blogbejegyzésben taglalja a részleteket:
„Jelentősen megváltoztattuk a JavaScript objektumok kezelését a Firefoxban. JavaScript objektum alatt érthetünk a scriptek által kezelt objektumokat, úgy mint tömböket és dátum objektumokat, de ide tartoznak a Dokumentum Objektum Modell (DOM) elemek is, úgy mint a beviteli mezők, vagy éppen a DIV elemek.
Régen a Firefox az összes JavaScript objektumot egy tárolóba helyezte el. Ezen a halmon végzett szemétgyűjtést (GC – Garbage Colletion) úgy, hogy a böngésző az összes objektumot ellenőrizte. A már elavult objektumokat törölte a program és az üres helyet felszabadította.

[…]
A Firefox 4-ben a JavaScript objektumok kezelés megváltozott. Az általunk fejlesztett JavaScript motor, a SpiderMonkey, most már támogatja a több halom használatát, amelyet rekeszeknek is nevezhetünk. Minden objektum meghatározható helyhez tartozik, így mindegyik helyhez hozzárendelhetünk egy saját rekeszt.„
Ez a megközelítés számos előnnyel jár, kezdve a biztonsági megfontolásoktól egészen a memóriakezelésre gyakorolt jótékony hátásáig. Például a weboldalak egymás objektumához való  hozzáférést csak a biztonságos és felügyelt átirányítóval (wrapper) lehet igénybe venni.

Lesz még jobb is

Abban az esetben, ha memóriakezelés megvalósítása tökéletes, a megoldás számos előny mellett csak minimális memóriatöbblettel jár. Noha a megoldás jó volt, a memóriafoglalás bizonyos esetekben szerencsétlenül alakult. Ennek tudható be, hogy a böngésző nem volt képes felszabadítani az összes memóriát.
A MemShrink projekt pont két hónapja alakult, s célja elsősorban az ehhez hasonló hibás memóriamenedzsmentből fakadó problémák feltárása és javítása.
A Firefox 7-ben már 20-30% memóriamegtakarítás biztosan látható lesz, de intenzív használat mellett akár még 50% feletti eredmény is nem elképzelhetetlen. Például a Legit Reviews szaklap „Our Test Shows Firefox 7 Aurora Uses Nearly 40 Percent Less Memory” cikkében 40 százalék csökkenésről számolt be: „a Firefox 5.0 memóriaigénye: 1 286 916 Kb, a Firefox 7.0 memóriaigénye: 776 392 Kb; 117 lap könyvjelzőből történő megnyitásakor.”

Hogy lehetséges ez?

A fejlesztések egyik iránya, hogy a rendszer számára külön rekeszt rendeltek a fejlesztők, így elkerülhető az a probléma, hogy a weblap bezárása után a weblap rekeszét „blokkolja” egy – a rendszerhez tartozó objektum. Ez akár több megabyte-nyi területet is jelenthet megnyitott webhelyenként. A tesztek tanúbizonysága szerint erre igen nagy az esély. A javítást már tartalmazza a héten Béta fázisba lépő Firefox böngésző 7-es verziója. (blog, 666058)
Egy gyors statisztika egy rövidke böngészési munkamenet után bezárt lapoknál:
108,003,328 B — js-gc-heap (javítás nélkül)
20,971,520 B — js-gc-heap (javítással)
A böngésző teljes memóriahasználata:
310,890,496 B — resident (without patch)
219,856,896 B — resident (with patch)
Ehhez a fejlesztéshez kapcsolódnak a Firefox memóriahasználatát jelentő oldal a „about:memory” fejlesztései is, amelyben a rekeszek memóriahasználata immáron külön-külön kerül kijelzésre, akárcsak a rendszer által használt rekeszek memóriaigénye. Egyre részletesebb eredményt is kapunk a különféle alrendszerek memóriahasználatáról, s csökken az azonosítatlan memóriafoglalás (heap-unclassified) is.
Ezzel kapcsolatban a tapasztaltabb – Nightly verzió használatától sem visszariadó – felhasználók zombivadászatra invitálja a MemShrink projekt vezető fejlesztője. A vadászat már elkezdődött, de sohasem késő kapcsolódni.
Visszatérve a memóriahasználatra, még meg kell említeni a hibás, kettő hatványainál éppen hogy nagyobb memóriafoglalást is, amely alapból közel 50%-nyi felesleges memóriát foglal az objektumoknak, bizonyos esetekben. A JavaScript karakterlánc-kezelése, a JS és PL arena allocator memóriakezelése, valamint a SQLite hibás memóriaigény jelzése is ilyen hibáktól volt terhelt.
Eközben a Web Workers új implementációja, az URL-kezelő (650649), az AUDIO és VIDEO tagekben megadott médiatartalom lejátszása is kevesebb memóriát igényel, s a böngésző jobban skálázódik a vetélytársaknál, sok lap megjelenítése esetén.
A JavaScript esetén komoly szerepe van a már említett szemétgyűjtésnek, így kisebb rekeszek ellenőrzése külön-külön gyorsabban lezajlik, ráadásul az objektumokat lezáró szál most már a háttérben fut le. A Firefox 6-tól kezdve a szemétgyűjtés sűrűbben megtörténik, mert nem csak a jelentős méretnövekedés válthatja ki a szemétgyűjtést, hanem állandó időközönként le fog futni ez a funkció (656120).

Ez még csak a kezdet

Ezek a fejlesztések együttesen adják a héten Béta fázisba kerülő Mozilla Firefox 7 memóriaigényének csökkenését. A csökkenés mértéke minimum 20%-30%, de a gyakorlat szerint ennél még nagyobb. A gyors fejlesztési ütemterv és a hatékonyan működő MemShrink munkacsoportnak hála 8 hét alatt számottevő javulás látható a memóriahasználat területén. Szerencsére a történet folytatódik, s a Firefox 8-ban további fejlődésnek lehetünk szemtanúi.