Det er almindeligt kendt, at moderne webapplikationer kører meget mere JavaScript-kode end for et par år siden. Selvom kompilatorer hurtigt har fulgt trenden og har gjort JavaScript effektiv, for Mozilla skal der implementeres en løsning, der håndterer denne arbejdsbyrde endnu bedre.
For at gøre dette, Mozilla har udviklet og tilføjet en ny bytecode-tolk JavaScript til sin JavaScript-gengivelsesmotor indbygget i Firefox 70. Da Firefox 70 er tilgængelig næste oktober, annoncerer Mozilla bedre JavaScript-kodeadministration ved at bruge sin nye kodetolk, der er føjet til JavaScript-motoren.
For at nå dette mål, Mozilla forklarer det I moderne JavaScript-motorer udføres hver funktion oprindeligt i en kodetolk.
Funktioner, der kaldes meget, kompileres til indbygget maskinkode. Dette kaldes en JIT-kompilering eller kompilering i farten. I forhold til Firefox inkluderer også en JavaScript-kodetolker skrevet i C ++ og forskellige niveauer af JIT-kompilering.
For det første har vi en grundlæggende JIT-kompilator, der kompilerer hver bytecode-sætning direkte i et lille stykke maskinkode ved hjælp af inline-cache til både ydeevne og informationsindsamling til JIT-kompilatoren kaldet IonMonkey eller Ion.
Til gengæld bruger IonMonkey-compileren avancerede optimeringer til at generere hurtig kode til kritiske muligheder.
Det skal bemærkes, at når en funktion, der allerede er under kompilering, kaldes med en ny type argument, kan koden i funktionen "de-optimeres" og droppes. I dette tilfælde fortsætter udførelsen i basiskoden indtil næste Ion-build.
Selvom denne fortolkningsproces af JavaScript-koden indtil videre har fungeret ganske godt, har teamet på Firefox forklarer, at den har stødt på nogle problemer med den første del består af C ++ tolk og JIT basecompileren.
Faktisk, nogle moderne webapplikationer som Google Docs eller Gmail køre så meget JavaScript, at compileren base og endda JIT-kompilatoren de kunne bruge lang tid på at forsøge at sammensætte tusinder af funktioner.
C ++-tolken har også været meget langsom og indsamler ikke typeoplysninger, hvilket forsinker grundlæggende kompilering. En løsning ville have været at trække den af tråden, men det ville have været en præstationsrisiko.
For at løse disse problemer kommenterer folkene fra Mozilla, at:
Basetolken er mellem C ++ tolken og basen JIT-kompilatoren og indeholder elementer fra begge niveauer.
Udfører alle bytecode-udsagn med en fast tolkesløjfe (som C ++ -tolken) og bruger inline cacheteknikker til at forbedre ydeevnen og indsamle typeoplysninger (som grundlæggende JIT gør).
At generere en tolk er ikke en ny idé. Men Firefox-teamet påpeger her, at de har fundet en ny måde at gøre dette ved at genbruge det meste af den grundlæggende JIT-compiler-kode. Den grundlæggende JIT-kompilator er en JIT-model, hvilket betyder, at hver mellemliggende kodeinstruktion kompileres til en i det væsentlige fast sekvens af maskininstruktioner, som derefter foreslås i en fortolkningsløbe.
Også siden Firefox-udviklere ønskede, at basetolken skulle bruge nøjagtigt de samme online caches og de samme oplysninger som JIT, blev der tilføjet en ny datastruktur kaldet JitScript.
JitScript indeholder al den typeinformation og inline cachedatastrukturer, der bruges af basetolkene og JIT-kompilatoren.
Med disse nye implementeringer findes de grundlæggende compiler-data for en funktion nu kun i maskinkode. Derfra er alle cachelagrede oplysninger og profileringsdata flyttet til JitScript.
På den anden side, da basetolken og JIT-kompilatoren er identiske, kan meget af den genererede kode også deles.
For at gøre dette blev en basisklasse kaldet BaselineCodeGen oprettet med 2 andre afledte klasser. Basecompileren bruger den første klasse BalineCompiler til at kompilere bytekoden for et script til maskinkode.
Den anden BaselineInterpreterGenerator-klasse bruges til at generere koden til basetolken. Og med BaselineInterpreterGenerator-klassen formåede Firefox-teamet at bygge basetolken.
kilde: https://hacks.mozilla.org/