Gå til indhold

Bytecode-VM

Vis som Markdown Rediger på GitHub Dokumentation hos 5b53f69

Standardstien til afvikling er en træfortolker — besøg hver AST-node, og returnér en værdi. For varme funktioner, der kaldes millioner af gange, er dispatch-overheadet pr. node flaskehalsen. Phasis tilføjer en spekulativ compiler fra bytecode til PHP-closures for at reducere dette overhead.

Hvornår VM'en aktiveres

Hver JsFunction har en tæller for varme kald. Når den overskrider en tærskel (som standard 100), forsøger motoren at kompilere funktionens body til en PHP-closure via src/Bytecode/JsToPhp.php.

Kompileringen lykkes, når funktionens body passer til et kendt sæt former:

  • Tildelinger til lokale variabler med forudsigelige typer (tal, objekt, funktion, array, streng).
  • Aritmetik med tal.
  • Medlemsopslag på lokale variabler med objekttype OG på this (this.v, obj.x).
  • Metodekald på lokale variabler med objekttype (obj.method(args)), hvor modtageren sendes med som $thisValue.
  • Kald af new Ctor(args)-konstruktører — opgraderer LHS-lokalvariablen til object som type og sætter en Bailout-vagt ved retur af andet end et objekt.
  • Løkker af typen for / while med enkle betingelser.
  • return med et beregneligt udtryk.
  • if / else over typede betingelser.

Kompileringen mislykkes (og funktionen forbliver på træfortolkeren), når bodyen indeholder:

  • with-sætninger.
  • try / catch / finally (håndteres af træfortolkeren for at sikre korrekt completion-semantik).
  • eval()-kald.
  • Direkte mutation af arguments.
  • Alt, som compileren endnu ikke ved, hvordan den skal sænke.

Når kompileringen lykkes, skifter motoren funktionens kaldesti til den kompilerede closure. Efterfølgende kald afvikler native PHP med overhead fra ét funktionskald i stedet for ét pr. AST-node.

Fallbacks

Den kompilerede hurtige sti bygger på antagelser (at tal forbliver tal, og at egenskaber forbliver på samme form). Når en antagelse brydes under kørsel, kaster closuren en Bailout, og afviklingen genstartes i træfortolkeren for det pågældende kald.

Det er her, korrekthed i forhold til specifikationen betyder mest. Træfortolkeren skal kunne genafvikle det kald, der udløste fallback, fra begyndelsen uden at observere bivirkninger fra den mislykkede hurtige sti. Phasis håndterer dette på to måder:

  1. Rene præfikser — compileren undersøger for bivirkninger før enhver spekulation. Hvis funktionen udfører I/O (console.log, værtsfunktioner) før spekulationspunktet, springer den hurtige sti ikke over dette; den gennemfører handlingen og fortsætter.
  2. Afvisning under kompilering — for former, der kræver tilbageførsel af observerbare bivirkninger (en ikke-numerisk let r = fn(), hvor fn() ændrer tilstand), afviser compileren at kompilere overhovedet. Funktionen bliver på træfortolkeren.

Det motiverende tilfælde: en ikke-numerisk tildeling udfører fn() på den hurtige sti, kaster Bailout og afvikles derefter igen i træfortolkeren — så fn() køres to gange med to sæt bivirkninger. Afvisning under kompilering forhindrer fn() i overhovedet at blive kørt på den hurtige sti, så træfortolkeren kun observerer det ene kald.

VM-dispatch (det andet lag)

Nogle funktioner kompileres til PHP-closures; andre falder videre til en endnu enklere bytecodefortolker i src/Bytecode/VM.php. Bytecoden er et fladt array af opcodes (LOAD_LOCAL, STORE_PROP, CALL_METHOD, …), som afvikles af en switch-dispatch.

VM'en bruges til funktioner, der ikke er værd at kompilere til en PHP-closure, men som stadig er varme nok til at drage fordel af at springe AST-gennemgangen over. Metodekald på indbyggede objekter (Array.prototype.map, String.prototype.split, …) går gennem hurtige stier i VM'en, der omgår den generiske callFunction-trampolin.

Brugerdefineret kaldestak

Op::CALL, Op::CALL_METHOD og Op::NEW_CALL bruger en inline-kaldesti, der holder hele JS-kaldestakken inden for VM::execute — ingen ny PHP-frame for hvert JS-kald. Ved indgang lægges kalderens tilstand (pc, kodestrøm, operandstak, lokale variabler, env, this, strict-mode-flag) i en pulje pr. VM med SavedFrame-instanser af typen savedFrames, hvorefter dispatch-løkken kobler sine lokale variabler om til den kaldte funktion. Op::RET fjerner den gemte frame fra puljen og gendanner den. Undtagelser afvikles gennem gemte frames, før de sendes videre til træfortolkeren.

Egnetheden gemmes i cache på JsFunction: vmInlineCallCache for almindelige kald (BC-kompileret body, ikke bundet til bind(), ikke native), vmInlineConstructCache for new-udtryk (derudover isConstructable, ikke nedarvet, ingen initialisering af instansfelter eller private metoder). Alt andet går stadig gennem den kanoniske callFunction-/vmNewExpression-trampolin.

Den arkitektoniske sidegevinst: grænsen for PHP-stakken begrænser ikke længere rekursionsdybden for JS. Nu er CallStack::maxDepth den eneste grænse — sat til 4 096, hvilket er komfortabelt over alle legitime test262-tilfælde (de fleste kræver under 2 k frames) og lavt nok til, at patologiske tests med uendelig rekursion fejler hurtigt inden for runnerens timeout. Stien med transpilerede closures (JsToPhp) har sin egen vagt på 8 192-frames for fallback uden inlining.

Generators med framesnapshot

Enkle generator-bodies — uden yield*, uden yield i try/catch/finally og uden await — kompileres til bytecode. Compileren udsender en ny Op::YIELD-opcode dér, hvor bodyen suspenderes; Op::YIELD indfanger dispatch-tilstanden (cf, pc+1, stack, sp, lokale variabler, env, thisValue, strict) i et GeneratorSnapshot-heapobjekt og returnerer en YieldResult-sentinel fra VM::execute. Den drivende JsGenerator gemmer snapshot'et og sender det tilbage til VM::execute ved næste next() / throw(), hvor resume-værdien øverst på operandstakken erstattes.

Dette erstatter PHP-Fiber-stien for det understøttede delmængde. Den Fiber-baserede driver (executeGeneratorBody) bruges stadig til former, som compileren afviser — yield*-delegering, generators, der giver værdier inde i en try-blok, async generators og async-funktioner med await. JsGenerator har to tilstande: hver next() / throw() / return() kontrollerer, om instansen har et snapshot eller en Fiber, og sender afviklingen videre derefter.

Der er ingen indstilling, som kan finjusteres med benchmarks; egnetheden afgøres ved kompilering og gemmes i cache på JsFunction. Gevinsten er ét færre kontekstskift i PHP pr. yield på snapshot-stien; Fiber-stien er uændret for alt andet.

Inline-caches

Op::LOAD_MEMBER har en inline-cache pr. pc, der er indekseret efter prototypeidentitet og bruges til mønsteret med prototypemetode på instans (c.sum(...), arr.push(...), alle dispatch af klassemetoder). Betingelse for cache-hit: modtageren har ingen egen slot for navnet, den cachelagrede prototypehenvisning er identisk med modtagerens getPrototype(), og prototypens PropertyMap::$version svarer stadig til den registrerede version.

Cache-invalidering bygger på PropertyMap::$version. Strukturelle ændringer (set / delete) øger den altid. Overskrivning af dataplotsværdi øger kun tælleren, når PropertyMap::$isUsedAsProto er sand — et write-barrier-flag, der slås til første gang objektet observeres som et andet objekts [[Prototype]]. Instansobjekter, der aldrig fungerer som prototyper, betaler intet for IC-infrastrukturen ved hver obj.x = v.

Getter-adgangsfunktioner cachelagres aldrig (de skal køres igen ved hver læsning).

PropertyMap har en ekstra tæller, $mutationVersion, som øges altid ved hver skrivning (uden write-barrier). JSON.stringify-cachen fastlåser denne tæller for hvert besøgt indlejret objekt/array, så en ændring, der kun påvirker instansen, som o.a = 99, korrekt invaliderer den cachelagrede streng, selv når IC'ens $version ville have sprunget tællerøgningen over.

JSON.stringify-cache

JsObject har $jsonCacheString + $jsonCacheVersions (en liste med [obj, mutationVersion]-par for hvert indlejret objekt, der blev besøgt under den trivielle stringify-gennemgang). Ved næste JSON.stringify(o)-kald uden replacer / space kontrollerer den trivielle hurtige sti, at alle fastlåste versioner er uændrede, og returnerer den cachelagrede streng uden at gennemgå eller kode data igen. Hyppige mønstre med dyb kloning som JSON.parse(JSON.stringify(o)) bliver cirka 2× hurtigere i stringify-delen.

Cachen droppes uden varsel ved cache-miss (hvis en fastlåst version afviger) og udfyldes igen ved næste gennemgang. Objekter med toJSON, getters, adgangsfunktioner, symboler eller [[PrimitiveValue]]-slots falder tilbage til specifikationens serialiseringsfunktion og udfylder aldrig cachen — den cachelagrede sti ser derfor kun strukturelt ensartede data.

Indbyggede hurtige stier

De største ydelsesforbedringer kom af at lære VM'en om specifikke indbyggede funktioner:

  • Atomics.load / store / compareExchange med loadSpinHook / storeNotifyHook kooperativ planlægning — genfandt 4 Atomics-tests med spin-løkker.
  • Date.prototype.getTimezoneOffset med en DST-cache baseret på direkte hashmap — 45 % hurtigere ved SpiderMonkey DST-belastningstest.
  • String.fromCharCode med en inline-hurtig sti til ASCII — sparer ~1 M dispatches pr. typisk gennemløb.
  • decodeURI / decodeURIComponent med en ultrahurtig sti til %XX%XX%XX%XX på 12 tegn, der bruger hex2bin-masséafkodning.
  • Object.keys / Object.values / Object.entries med direkte adgang til egenskabskortet.
  • Array.prototype.map / filter / forEach / reduce med indbygget iteration over det underliggende PHP-array.

Hver hurtig sti styres af et "formtjek" — hvis modtageren ikke har den forventede form (e.g. en TypedArray-visning, der ikke er understøttet af en almindelig PHP string), falder VM'en tilbage til den langsomme sti, der følger specifikationen.

Hvad dette ikke gør

Bytekode-VM'en er ikke en JIT i V8-forstand. Den genererer ikke native maskinkode pr. funktion og spekulerer ikke ud fra observerede typer ud over IC'ens monomorfe tjek af prototypeidentitet. Inlining ved funktionsgrænser efterlignes med den tilpassede kaldestak (ingen ekstra PHP-ramme pr. JS-kald) i stedet for at sænke den kaldte funktions krop til den kaldende funktions bytekode.

JsToPhp-transpileren er det nærmeste, motoren kommer på en JIT: den genererer PHP-kildekode til varme funktionskroppe, som PHP 8.5's sporings-JIT derefter kompilerer til native kode. JsToPhp går gennem eval() og betaler derfor en engangsudgift til kompilering, mens sporings-JIT'en skal opdage funktionen, som om den var brugerkode. Hvis eval()-trinnet springes over ved at generere opcache-opkoder direkte, ville forskellen blive mindre — se Benchmarks § Roadmap.

Benchmark

bench/microbench.js kører et dusin og lidt til små benchmarks (loop-arith, loop-fib, fn-recurse, fn-deep-recurse, obj-create, obj-prop, proto-method, gen-iterate, arr-push, arr-map, str-concat, str-split-join, json-roundtrip, closure, destructure). Median køretid:

Shell
php bench/run.php

De aktuelle tal gemmes i BENCH.md efter hver kørsel af bench-workflowen. Workflowene for bench og test262-matricen startes begge manuelt.