Sådan skrev vi Googles JavaScript-motor i Århus
SAN FRANCISCO. Google har i to år haft en afdeling i Katrinebjerg i Århus, men selskabet har hele tiden holdt tæt med, hvad der foregik i den danske afdeling.
Nu er hemmelighedskræmmeriet forbi. Googles danske projekt har været udviklingen af selskabets virtuelle maskine til hurtigere afvikling af JavaScript, V8, som er en central del af Googles nye webbrowser Chrome.
»Selvfølgelig har det været irriterende, at vi ikke har kunnet tale om, hvad vi har lavet i Århus,« fortæller softwareudvikler Lars Bak til Version2.dk.
Han er én af hovedmændene bag V8 med mere end otte års erfaring inden for udvikling af virtuelle maskiner. Derfor er han nu glad for at få lov til at vise, hvad Googles danske hold har skabt, som ikke kun kommer Google til gode.
»Det hele bliver frigivet som open source. Vi håber, at vi kan være med til at forbedre JavaScript i alle browsere, og at det er noget, alle vil bruge,« siger Lars Bak.
Udviklet helt fra bunden
Bortset fra to komponenter er hele JavaScript-motoren udviklet fra grunden af i Århus. Google ønskede en ny motor, som skulle gøre det muligt at køre browserbaserede applikationer med meget mere JavaScript hurtigere end det hidtil har været muligt.
Løsningen er en ny virtuel maskine, som imidlertid gav særlige udfordringer på grund af, at JavaScript er et dynamisk sprog.
»Det var nødvendigt for os at finde på nye teknikker. JavaScript er ikke baseret på klasser, så når du har to objekter, så har de ikke noget til fælles,« forklarer Lars Bak.
I praksis deler objekterne selvfølgelig egenskaber, og derfor er et centralt trick i den virtuelle maskine at finde frem til og opbygge de objektklasser, der ligger gemt i koden.
»Når vi så har gjort det, kan vi begynde at bruge konventionelle teknikker til optimering i den virtuelle maskine,« forklarer Lars Bak.
Samtidig indeholder den nye JavaScript-motor en kompiler eller oversætter, som skaber kode, der kører direkte på pc'en, og som lærer fra det kørende program og tilpasser det.
Bedre garbage collector
For at kunne køre længere programmer i JavaScript på den nye motor har det danske hold også skabt en bedre garbage collector. Problemet med JavaScript-applikationer er blandt andet, at de ofte skaber et stort antal objekter, som kun skal bruges kortvarigt.
Garbage collection er derfor nødvendigt, fordi sproget ikke selv rydder op i objekterne, når de ikke længere skal bruges, men det er ikke ligegyldigt, hvordan det sker. I V8 har Google derfor implementeret en garbage collector, som kun skaber meget korte pauser, mens der bliver ryddet op, så brugeren ikke oplever forsinkelser fra oprydningen.
Selvom den nye JavaScript-motor allerede nu giver en bedre ydelse i eksisterende browserbaserede applikationer, så skal den store gevinst hentes på længere sigt.
»Ydelsen i JavaScript har været en flaskehals, så udviklerne har været påpasselige. V8 gør en forskel allerede i dag, men potentialet ligger i at lave applikationer, som bruger endnu mere JavaScript,« siger Lars Bak.
»Nu om dage sender en webbaseret applikation de tunge opgaver retur til en server, så hastigheden bliver afhængig af netværksforsinkelsen. En hurtigere JavaScript-motor gør det muligt at køre mere og mere JavaScript inde i browseren,« slutter han.
Kommentarer (1)
Hurtigere JavaScript er et vigtigt mål for den næste generation af webbrowsere, der skal supportere stadig større og mere krævende applikationer - det er Google ikke de eneste, der har regnet ud.
TraceMonkey er en anden JavaScript motor, der skulle dukke op i en kommende version af FireFox (måske 3.1?) ... projektet er kun nogen måneder gammelt, men er allerede hurtigere i visse tests, end V8:
http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_upda...
I enkelte rekursive tests, er V8 stadig betydelig hurtigere end TraceMonkey, men de har efter sigende allerede en løsning på tegnebrædtet til at optimere rekursion...
Det bliver derfor nok ikke V8, der havner i Firefox, men sikkert TraceMonkey, der efter sigende også er designet med udviklere i øjemed - denne motor skulle give udviklere mulighed for at spore kald gennem en form for stak; noget, der ellers ikke er nemt (eller i nogen motorerer umuligt) i JavaScript...

