Többszálúsításra tör a Firefox
Célegyenesbe fordul lassan az Electrolysis, a Firefox folyamatokra bontására irányuló projekt. Bár a felhasználói felület és a tartalom különválasztása csak az első lépés lesz, a Mozillánál tisztában vannak az összes tennivalóval.
A Firefox számára a fő alkalmazás folyamatokra (process) bontása lassan a termékfejlesztés Szent Gráljává vált, ahogy a jelenlegi, monolitikus alkalmazásarchitektúra egyre inkább hátráltatja a böngészőt. Az első nagy lépés régen megszületett, a bővítményeket már a 3.6.4 verzió óta külön kezeli a böngésző, de magának a motornak a feldarabolása azóta sokkal lassabban halad. Chris Blizzard, a Mozilla webes platformjáért felelős vezetője blogposztjában felsorolta az elérhető előnyöket.
Szünetmentes
A többszálúsítás mellett szóló legfontosabb érv a felhasználó által érzékelt sebesség növekedése. A Mozilla szerint jelenleg a Firefox sok esetben lassan reagál a bevitelre, hosszú tizedmásodpercekig szünetel - ezt pedig a felhasználók érzékelik és irritálónak tartják. Ez a fajta lassúság a tipikus benchmarkokkal azonban mérhetetlen, ugyanis a háttérben futó folyamatokat nem zavarja. Az apró szünetek elsősorban annak tudhatóak be, hogy a fő alkalmazásfolyamat a háttérben szemétgyűjtéssel (garbage collection) van elfoglalva, és nem tudja azonnal frissíteni a felhasználói felületet.
Az Electrolysis néven hosszú ideje futó belső projekt célja második lépésben tehát csupán annyi, hogy leválassza a fő alkalmazásfolyamatról a felhasználói felületért és megjelenítésért felelős részt, ami a jövőben külön futna. Így a háttérben futó folyamatok nem blokkolnák a processzoridőre vágyó felhasználói felületet, ez pedig gyorsabban reagáló alkalmazást jelent.
Túl nagy halom
Jelen pillanatban a szemétgyűjtés két szempontból is zavart okoz a Firefox működésében. Egyrészt ha az alkalmazás egyetlen folyamatként működik, sok megnyitott fül esetében már hatalmas heap (halom) gyűlik össze, amelynél a garbage collection már nagyon hosszú ideig tart. Blizzard szerint ezen a téren történt már előrelépés, a szünetek azonban még mindig megállítják a főfolyamatot. A megoldás a folyamat (és ezzel a heap) feldarabolása, amelyeken a szemétgyűjtés sokkal gyorsabban végigmegy, így egyetlen szünet helyett több apró keletkezik - ezek pedig jó eséllyel a felhasználó ingerküszöbe alatt maradnak.
A másik problémát maga a szemétgyűjtés és az interfész-folyamat viszonya jelenti. Az olyan webes alkalmazások, mint a Gmail, Facebook, Twitter rengeteg memóriát fogyasztanak és sűrű szemétgyűjtést igényelnek, ilyenkor pedig pillanatokra megáll a teljes böngésző. A fülekhez saját folyamat rendelése itt nem segít különösebben, a valódi megoldás a felhasználói felület és a tartalom-folyamatok teljes különválasztása lesz.
Sokmagos fejfájás
A tartalommegjelenítésben a Firefox már egyre több helyen kihasználja a többmagos processzorok előnyeit, például videomegjelenítésben vagy a képek és hangok dekódolásánál, de külön utasításszálat kapnak a hálózati- és I/O-műveletek is. Az alapvető webes technológiák, mint a DOM, a JavaScript és a CSS feloldása azonban egyelőre csak egyetlen utasításszálon futnak. Ez nyilván nem ideális, ahogy az asztali számítógépekben és notebookokban már évek óta, a mobileszközökben pedig mostantól lehet számítani a többmagos processzorokra. A rövid távú gyógyír erre minden DOM saját processzormaghoz rendelése lesz, vagyis minden oldal saját folyamata saját magot kap. A hosszútávú megoldást a Rust programozási nyelv jelentheti, amelyet az alapoktól a többszálú végrehajtásra íródott.
Blizzard bejegyzésében beismeri, hogy súlyos problémák vannak a böngésző memóriakezelésével is. A hosszas használat alatt a Firefox által felhasznált memóriaterület töredezetté válik, és a C illetve C++-ra épülő Firefox alkalmazás ezt nem képes megfelelően kezelni, mivel a gráfobjektumok sokszor nem mozdíthatóak. Ennek köszönhetően idővel a heap mérete megnő, a memória pedig "szivárogni" kezd. A haladó számítógép-felhasználók számára a probléma ismerős, "a komplex allokációs mintákkal rendelkező, hosszú ideig futó folyamatok gyakorlatilag mind ilyenek" - állítja Blizzard. A megoldást itt is a folyamatokra bontás hozza el: a bezárt oldalak ugyanis egyenesen az operációs rendszernek adják vissza az elfoglalt memóriaterületet, így az folyamatosan újrahasznosítható.
A memóriahasználat csökkentésén azonban ettől függetlenül is dolgozik a Mozilla, a Memshrink projekt keretében. A nemrég kiadott 7-es Firefox Aurora verzióban már benne vannak az első eredmények, a felhasználók mintegy 30-40 százalékkal kisebb elfoglalt memóriaterületről számolnak be. Sajnos a projekt nem halad zökkenőmentesen, néhány nagyobb lélegzetvételű változást vissza kellett vonni - a Mac OS X alá készülő verzióból így egyelőre kikerült a jemalloc támogatás, a JavaScript típuskövetkeztető pedig bár jelentős sebességnövekedést hozott, túl nagy memóriahasználattal járt. A Memshrink projekt ettől függetlenül folyamatosan halad, az elért eredmények pedig a következő iterációkban még látványosabbak is lehetnek.
Biztonság és összeomlás-védelem
A beépülő modulok összeomlása a 3.6.4-es verzió óta nem rántja magával a böngészőt - ezt a Flash hagyományos megbízhatatlansága miatt kényszerült meglépni a Mozilla. A modulok azóta külön folyamatban futnak, amely ha összeomlik, akkor nem befolyásolja a főfolyamatot. A fülenként külön folyamatra bontás azonban továbblépést jelentene a problémás oldalak különválasztásában, így a lassú vagy összeomló tartalom sem lenne hatással a többi oldalra illetve a böngészőre.
Égbe révedő informatikusok: az Időkép-sztori Mi fán terem az előrejelzés, hogy milyen infrastruktúra dolgozik az Időkép alatt, mi várható a deep learning modellek térnyerésével?
Az utolsó megfontolás a biztonságot érinti. A modern operációs rendszerek képesek egyes folyamatokat alacsony jogokkal ellátni, amelyek így nem férnek hozzá a fontos erőforrásokhoz. Ennek megfelelően a feltört böngészőfolyamatból a rosszindulatú kód nem tud kitörni az operációs rendszer felé - vagyis a károkozás lehetősége korlátozott. A sandboxing természetesen nem teljes körű, a folyamatok kommunikálnak a magasabb hozzáféréssel rendelkező főfolyamattal, de mindenképp egy hozzáadott sorompót jelent a kártékony kód előtt.
64 biten?
A Mozilla elkezdett dolgozni a Windows-platform számára a böngésző 64 bites verzióján is - legalábbis erre utal a böngésző asztali változatának fejlesztéséért felelős Asa Dotzler felhívása, amelyben arra kéri az olvasókat, hogy jelöljék ki a 64-bites változat céljait és lehetséges problémáit. Egyelőre a magasabb teljesítmény és a jobb biztonság szerepel az előnyök között, a hátrányok közé pedig a felhasználók megzavarására alkalmas új verzió megjelenése, a beépülő modulokkal kapcsolatos problémák, valamint a tovább duzzadó memóriahasználat került. A felhívás szövegéből is kitűnik, hogy a munka még csak az előkészítés és tervezés fázisában van, a 64-bites windowsos technológia érettségét ismerve azonban valószínűleg nem kerül sok időbe a böngésző újrafordítása.