Mozilla Servo: równoległe renderowanie stron w mobilnych przeglądarkach coraz bliższe

Początki przeglądarek Mozilli nierozłącznie wiążą się zodziedziczonym po Netscape silnikiem renderującym Gecko (znanymwówczas jeszcze pod nazwą NGLayout), który zadebiutował niemal 14lat temu w przeglądarce Netscape 6. Od pojawienia się Phoeniksa w2002 roku (który później zmienił nazwę na Firebirda, którypóźniej zmienił nazwę na Firefoksa), Gecko rozwijało się zprzeglądarką Mozilli, dzięki staraniom jej deweloperów i jejspołeczności. Przez ten czas znalazło zastosowania w innychprojektach, zarówno Mozilli (jak np. Thunderbird czy Sunbird) jak iniezależnych programistów (np. przeglądarce Lunascape czyodtwarzaczu muzyki Nightingale), a w końcu stało się kluczowymkomponentem mobilnego systemu operacyjnego Firefox OS. Jednakpotrzeby mobilnych aplikacji niekoniecznie pokrywają się zpotrzebami aplikacji pisanych na desktop i to właśnienajprawdopodobniej jest powodem, dla którego Mozilla widziprzyszłość, w której Gecko zostaje porzucone na rzecz zupełnienowego silnika, najwyraźniej rozwijanego z myślą przede wszystkimo Firefox OS-ie i Firefoksie dla Androida.

W kwietniu zeszłego roku programiści Mozilli i Samsungapołączyli siły w pracy nad Servo – silnikiem renderującym dlaprzeglądarek, który miałby zapewnić pełne wykorzystaniewielordzeniowej architektury współczesnych procesorów. Wówczasnajwiększe zainteresowanie wzbudził nie sam silnik, ale język, wjakim był on pisany. Opracowany przez Mozilla Research językprogramowania Rust daje deweloperom wydajność porównywalną z C++,ale bez ryzyka związanego z masową produkcją błędów obsługiipamięci, typowych dla aplikacji pisanych w C++. Zapewnia teżwbudowane w samą strukturę języka mechanizmy współbieżności,ułatwiające bezpieczną paralelizację kodu dla różnychscenariuszy.

Sam silnik renderujący, którego nazwa nawiązuje do robota TomaServo z klasycznego serialu komediowego science fiction MST3K,przedstawiono wówczas jako eksperyment badawczy, podkreślając, żenie ma żadnych planów, by integrować go z istniejącymi produktamiMozilli. Jak faktycznie wówczas producent Firefoksa na to patrzył– nie wiadomo, trzeba pamiętać jednak o kontekście wydarzeń:Opera zrezygnowała ze swojego silnika, zaś deweloperzy Chromeogłosilli, że kończą z oficjalnym WebKitem i przechodzą na nowysilnik Blink – fork WebKitu robiony wyłącznie z myślą ogoogle'owej przeglądarce. Analogiczne deklaracje dla zrośniętego zGecko Firefoksa byłyby przedwczesne, i mogłyby wywołać jedynieobawy o przyszłość tej przeglądarki.

W rzeczywistości Servo wyglądało na coś więcej, niż tylkobadawczy projekt. Dla Mozilli, coraz bardziej zaangażowanej w rozwójproduktów mobilnych, Gecko zaczynało być kulą u nogi. Problemtkwi w tym, że renderowanie dokumentów HTML jest dziś procesem,który paralelizuje się w bardzo ograniczonym stopniu. Choćniektóre zadania, takie jak dekompresja mediów, czy uruchamianieskryptów można przerzucić na inne rdzenie, to zdecydowanawiększość pracy wykonywana jest w jednym wątku, na jednymrdzeniu. Gdy przeglądarkę uruchamiamy na maszynie, której sercemjest Core i5 czy i7, to nie boli. Gdy jednak przychodzi douruchamiania przeglądarki na rdzeniach ARM, sytuacja jest znaczniegorsza. Topowe mikroprocesory na tej architekturze, takie jakSnapdragon 800 czy Tegra 4 osiągają w benchmarkach dlapojedynczych rdzeni kilkukrotnie gorsze wyniki, niż topowemikroprocesory z rdzeniami x86-64. O wiele zaś dziś łatwiej dodaćw układach SoC ARM więcej rdzeni, niż zwiększyć wydajnośćpojedynczego rdzenia.

Servo elegancko obchodzi ten problem, rozbijając renderowaniedokumentu na wyliczanie layoutu, renderowanie treści i wykonywanieskryptów. Wszystkie te zadania wykonywane są równoległe naoddzielnych rdzeniach, a co więcej, możliwa jest dalsza ichparalelizacja. To zasługa języka Rust, w którym każdezadanie jest izolowane od innych, a komunikacja między nimi zachodziasynchronicznie. Dzięki temu gdy Servo musi przeskalować rozmiarokienka, wyliczenie layoutu nie musi czekać na wyliczenieistniejącej już treści. Tak samo Servo uniezależnia renderowaniestron od zawartych w nich czasami pływających ramek (iframe) –zamiast wyliczać je w jednym wątku, zostają przeniesione dowłasnego zadania przerzuconego na oddzielny rdzeń.

Równie interesujące jest równoległe wyliczanie layoutu przezServo. Zamiast zaczynać od najwyższych elementów strony (html,body, itd...) i schodzić w głąb drzewa rozgałęzień, ustalającwzajemne położenie elementów potomnych, nowy silnik Mozilliwyszukuje najpierw wzajemnie niezależne obszary strony i układa jerównoległe, w niezależnych zadaniach, posyłanych tym rdzeniom,które akurat są najmniej obciążone.

W ten sposób Servo nie tylko przyspiesza działanie mobilnejprzeglądarki, ale też zmniejsza zużycie energii: jeden rdzeńobciążony w 100% jest o wiele większym obciążeniem dlaakumulatora niż cztery rdzenie obciążone w 30-40%. Ludzie zMozilli i Samsunga są przekonani więc, że dzięki paralelizacjimogą uzyskać znacząco dłuższy czas pracy na baterii.

Jak na razie nowym silnikiem Mozilli bawi się mało kto pozaczłonkami zespołu i grupą testerów. Dostępny jest tylko kodźródłowy na Githubie, możliwy do skompilowania na Linuksie,OS-ie X i dla Androida (pod którego jest najbardziejoptymalizowany). Nikt na razie nie potrafi skompilować go naWindows. Brakuje mu też obsługi wielu API modelu DOM, obsługilicznych właściwości CSS – ale deweloperzy projektu sąoptymistami. Niewielki zespół uważa, że binarne wersje silnikazostaną pokazane już w drugim kwartale, a jeszcze w tym roku Servobędzie nadawało się do użytku (przynajmniej wewnętrznie, wMozilli). Kiedy nowy silnik trafi do mobilnego Firefoksa oraz FirefoxOS-a, jeszcze nie wiadomo, ale niewykluczone, że stanie się to jużw 2015 roku. W sytuacji, gdy coraz częściej procesory ARM zawierającztery i więcej rdzeni, dałoby to Mozilli ogromną przewagę wdziedzinie mobilnych przeglądarek.

Wszystkiego, co można się dowiedzieć o Servo, dowiecie się z wiki projektu, dostępnej tutaj.