VM à bytecode

Le chemin d’exécution par défaut est un interpréteur arborescent : il visite chaque nœud de l’AST et renvoie une valeur. Pour les fonctions très sollicitées, appelées des millions de fois, le surcoût du dispatch par nœud devient le goulot d’étranglement. Phasis ajoute par-dessus un compilateur spéculatif qui convertit le bytecode en closures PHP afin de réduire ce surcoût.

Quand la VM se met en marche

Chaque JsFunction possède un compteur d’appels à chaud. Lorsqu’il dépasse un seuil (100 par défaut), le moteur tente de compiler le corps de la fonction en closure PHP via src/Bytecode/JsToPhp.php.

La compilation réussit lorsque le corps de la fonction correspond à un ensemble connu de formes :

• Affectations de variables locales dont les types sont prévisibles (numérique, objet, fonction, tableau, chaîne).
• Opérations arithmétiques sur des nombres.
• Lectures de membres sur des variables locales de type objet ET sur this (this.v, obj.x).
• Appels de méthodes sur des variables locales de type objet (obj.method(args)), avec transmission du récepteur sous la forme $thisValue.
• Appels de constructeur new Ctor(args) — le type de la variable locale LHS devient object et un garde d’abandon vérifie que la valeur renvoyée n’est pas un objet.
• Boucles for / while avec des conditions simples.
• return avec une expression calculable.
• if / else sur des conditions typées.

La compilation échoue (et la fonction reste exécutée par l’interpréteur arborescent) si le corps contient :

• Des instructions with.
• try / catch / finally (pris en charge par l’interpréteur arborescent pour respecter la sémantique d’achèvement).
• Des appels eval().
• Une modification directe de arguments.
• Toute construction que le compilateur ne sait pas encore convertir.

Lorsque la compilation réussit, le moteur remplace le chemin d’appel de la fonction par la closure compilée. Les appels suivants exécutent du code natif PHP avec le surcoût d’un seul appel de fonction, au lieu d’un surcoût par nœud de l’AST.

Abandons

Le chemin rapide compilé repose sur des hypothèses (les nombres restent des nombres, les propriétés conservent la même forme). Si une hypothèse est invalidée à l’exécution, la closure déclenche un Bailout et l’exécution reprend dans l’interpréteur arborescent pour cet appel.

C’est là que la conformité à la spécification est essentielle. L’interpréteur arborescent doit pouvoir réexécuter depuis le début l’appel qui a déclenché l’abandon, sans observer d’effets de bord du chemin rapide ayant échoué. Phasis gère cela de deux façons :

1. Préfixes purs — le compilateur recherche les effets de bord avant toute spéculation. Si la fonction effectue des E/S (console.log, fonctions hôtes) avant le point de spéculation, le chemin rapide ne les supprime pas : il valide les opérations et poursuit l’exécution.
2. Refus à la compilation — pour les formes qui nécessiteraient d’annuler des effets de bord observables (une affectation let r = fn() non numérique où fn() modifie l’état), le compilateur refuse toute compilation. La fonction reste exécutée par l’interpréteur arborescent.

Cas à l’origine de cette approche : une affectation non numérique exécute fn() sur le chemin rapide, déclenche Bailout, puis est réexécutée par l’interpréteur arborescent — fn() s’exécute alors deux fois, avec deux séries d’effets de bord. Le refus à la compilation empêche fn() de s’exécuter sur le chemin rapide, si bien que l’interpréteur arborescent ne voit qu’un seul appel.

Dispatch de la VM (la deuxième couche)

Certaines fonctions sont compilées en closures PHP ; les autres passent par un interpréteur de bytecode encore plus simple dans src/Bytecode/VM.php. Le bytecode est un tableau plat d’opcodes (LOAD_LOCAL, STORE_PROP, CALL_METHOD, …) exécutés par un dispatch switch.

La VM sert aux fonctions qui ne justifient pas une compilation en closure PHP, mais sont assez sollicitées pour profiter de l’absence de parcours de l’AST. Dans la VM, les appels de méthodes sur des objets intégrés (Array.prototype.map, String.prototype.split, …) empruntent des chemins rapides qui contournent le trampoline générique callFunction.

Pile d’appels personnalisée

Op::CALL, Op::CALL_METHOD et Op::NEW_CALL empruntent un chemin d’appel intégré qui conserve toute la pile d’appels JS dans VM::execute : aucune nouvelle frame PHP par appel JS. À l’entrée, l’état de l’appelant (pc, flux de code, pile des opérandes, variables locales, env, this, indicateur de mode strict) est empilé dans un pool savedFrames par VM d’instances SavedFrame, et la boucle de dispatch redirige ses variables locales vers celles de l’appelé. Op::RET dépile la frame sauvegardée et restaure l’état. Les exceptions remontent à travers les frames sauvegardées avant de revenir à l’interpréteur arborescent.

L’éligibilité est mémorisée dans JsFunction : vmInlineCallCache pour les appels ordinaires (corps compilé en bytecode, sans liaison avec bind(), non natif), vmInlineConstructCache pour les expressions new (avec en plus isConstructable, non dérivé, sans initialiseur de champ d’instance ni de méthode privée). Les autres cas passent toujours par le trampoline canonique callFunction / vmNewExpression.

Avantage architectural supplémentaire : la limite de pile PHP ne plafonne plus la profondeur de récursion de JS. CallStack::maxDepth est désormais la seule limite — fixée à 4 096, bien au-delà des cas légitimes de test262 (la plupart nécessitent moins de 2 k frames) et assez basse pour que les tests de récursion infinie pathologiques échouent rapidement, dans le délai d’attente de l’exécuteur. Le chemin des closures transpilées (JsToPhp) dispose de son propre garde-fou de 8 frames 192 pour le repli non intégré.

Générateurs à instantané de frame

Les corps de générateur simples — sans yield*, sans yield dans un bloc try/catch/finally, sans await — sont compilés en bytecode. Le compilateur émet un nouvel opcode Op::YIELD à l’endroit où le corps suspend son exécution ; Op::YIELD capture l’état du dispatch (cf, pc+1, pile, sp, variables locales, env, thisValue, strict) dans un objet GeneratorSnapshot du tas et renvoie un marqueur sentinelle YieldResult depuis VM::execute. Le pilote JsGenerator stocke l’instantané et le transmet à VM::execute au prochain next() / throw(), en remplaçant la valeur de reprise au sommet de la pile des opérandes.

Cela remplace le chemin Fiber PHP pour le sous-ensemble pris en charge. Le pilote fondé sur Fiber (executeGeneratorBody) reste utilisé pour les formes rejetées par le compilateur : délégation yield*, générateurs qui produisent une valeur dans un bloc try, générateurs asynchrones, fonctions asynchrones avec await. JsGenerator fonctionne dans les deux modes : à chaque next() / throw() / return(), il vérifie si l’instance possède un instantané ou une Fiber et effectue le dispatch en conséquence.

Aucun paramètre ajustable par benchmark : l’éligibilité est déterminée à la compilation et mémorisée dans JsFunction. Le gain correspond à un changement de contexte PHP en moins par valeur produite dans le chemin par instantané ; le chemin Fiber reste inchangé pour tous les autres cas.

Caches inline

Op::LOAD_MEMBER possède un cache inline par PC, indexé par identité du prototype, pour le cas d’une méthode de prototype appelée sur une instance (c.sum(...), arr.push(...), chaque dispatch de méthode de classe). Le cache est utilisé si le récepteur n’a pas de propriété propre portant ce nom, si la référence de prototype mise en cache est identique à celle de getPrototype() du récepteur, et si le PropertyMap::$version du prototype correspond toujours à la version enregistrée.

L’invalidation du cache repose sur PropertyMap::$version. Les mutations structurelles (définition ou suppression) l’incrémentent systématiquement. Les remplacements de valeur d’un emplacement de données ne l’incrémentent que si PropertyMap::$isUsedAsProto vaut vrai — un indicateur de barrière d’écriture activé dès que l’objet est observé pour la première fois comme [[Prototype]] d’un autre objet. Les objets d’instance qui ne servent jamais de prototypes n’ont aucun coût lié à l’infrastructure de cache inline à chaque obj.x = v.

Les accesseurs getter ne sont jamais mis en cache (ils doivent être réexécutés à chaque lecture).

PropertyMap possède un second compteur, $mutationVersion, qui s’incrémente systématiquement à chaque écriture (sans barrière d’écriture). Le cache JSON.stringify épingle ce compteur pour chaque objet ou tableau imbriqué visité afin qu’une mutation d’une instance seulement, comme o.a = 99, invalide bien la chaîne mise en cache même lorsque le $version du cache IC aurait omis l’incrément.

Cache JSON.stringify

JsObject conserve $jsonCacheString + $jsonCacheVersions (une liste de paires [obj, mutationVersion] pour chaque objet imbriqué rencontré lors du parcours trivial de stringify). Au prochain appel JSON.stringify(o) sans fonction de remplacement ni indentation, le chemin rapide trivial vérifie que chaque version épinglée est inchangée, puis renvoie la chaîne en cache sans nouveau parcours ni encodage. Les schémas courants de clonage profond, comme JSON.parse(JSON.stringify(o)), accélèrent d’environ 2× la partie stringify.

En cas d’échec (une version épinglée a changé), le cache est supprimé sans notification et rempli de nouveau lors du prochain parcours. Les objets avec toJSON, getters, accesseurs, symboles ou emplacements [[PrimitiveValue]] passent par le sérialiseur conforme à la spécification et ne remplissent jamais le cache : le chemin mis en cache ne traite donc que des données uniformes sur le plan structurel.

Chemins rapides intégrés

Les gains de performances les plus importants sont venus de l’ajout de chemins rapides spécifiques à certains éléments intégrés dans la VM :

• Atomics.load / store / compareExchange avec planification coopérative loadSpinHook / storeNotifyHook — quatre tests de boucles d’attente Atomics récupérés.
• Date.prototype.getTimezoneOffset avec un cache DST fondé directement sur une hashmap — gain de vitesse de 45 % sur les tests de résistance DST de SpiderMonkey.
• String.fromCharCode avec un chemin rapide ASCII intégré — environ 1 M de dispatchs économisés par parcours type.
• decodeURI / decodeURIComponent avec un chemin ultra-rapide %XX%XX%XX%XX de 12 caractères, utilisant le décodage groupé hex2bin.
• Object.keys / Object.values / Object.entries avec accès direct à la map des propriétés.
• Array.prototype.map / filter / forEach / reduce avec itération native sur le tableau PHP sous-jacent.

Chaque chemin rapide est soumis à une « vérification de forme » : si le récepteur ne correspond pas à la forme attendue (e.g, une vue TypedArray qui ne repose pas sur un PHP string simple), la VM revient au chemin lent conforme à la spécification.

Ce que cela ne fait pas

La VM à bytecode n’est pas un JIT au sens de V8. Elle ne génère pas de code machine natif pour chaque fonction et ne spécule pas sur la base des types observés, au-delà du contrôle monomorphe d’identité de prototype du cache IC. L’intégration aux frontières des fonctions est simulée par la pile d’appels personnalisée (aucune frame PHP supplémentaire par appel JS), plutôt que par la conversion du corps de l’appelé en bytecode de l’appelant.

Le transpileur JsToPhp est ce qui se rapproche le plus d’un JIT dans le moteur : il génère du code source PHP pour les corps des fonctions à chaud, que le JIT de traçage de PHP 8.5 compile ensuite en code natif. JsToPhp passe par eval(), ce qui entraîne un coût de compilation initial ; le JIT de traçage doit ensuite découvrir la fonction comme s’il s’agissait de code utilisateur. Éviter l’étape eval() en émettant directement des opcodes opcache réduirait davantage l’écart — voir Benchmarks § Feuille de route.

Benchmarks

bench/microbench.js exécute une quinzaine de petits 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). Temps mural médian :

php bench/run.php

Les chiffres actuels sont enregistrés dans BENCH.md après chaque exécution de workflow bench. Les workflows bench et de la matrice test262 sont tous deux lancés manuellement.