Faire fonctionner JavaScript rapidement est essentiel pour une application web réactive. Même avec les optimisations avancées de V8, analyser et compiler le JavaScript critique lors du démarrage peut toujours être une source de ralentissements. Savoir quelles fonctions JavaScript compiler lors de la compilation initiale du script peut accélérer le chargement de la page web.

Le compilateur optimisant de V8, Turbofan, est renommé pour être l’un des rares compilateurs de production à grande échelle à utiliser Sea of Nodes (SoN). Cependant, depuis près de 3 ans, nous avons commencé à nous débarrasser de Sea of Nodes et à revenir à une représentation intermédiaire (IR) plus traditionnelle avec le Control-Flow Graph (CFG), que nous avons nommé Turboshaft. Aujourd’hui, tout le backend JavaScript de Turbofan utilise Turboshaft, et WebAssembly utilise Turboshaft tout au long de son pipeline. Deux parties de Turbofan utilisent encore la mer des nœuds : le pipeline intégré, que nous remplaçons progressivement par Turboshaft, et le frontend du pipeline JavaScript, que nous remplaçons par Maglev, une autre IR basée sur CFG. Ce post explique les raisons qui nous ont poussés à abandonner la mer des nœuds.

Chez V8, nous nous efforçons constamment d'améliorer les performances de JavaScript. Dans le cadre de cet effort, nous avons récemment revisité la suite de tests JetStream2 pour éliminer les goulets d'étranglement de performance. Cet article détaille une optimisation spécifique que nous avons réalisée et qui a permis une amélioration significative de 2.5x dans le test async-fs, contribuant ainsi à une augmentation notable du score global. L'optimisation a été inspirée par le test, mais de tels motifs apparaissent également dans le code du monde réel.

L'API d'intégration des Promises JavaScript (JSPI) permet aux applications WebAssembly écrites en supposant un accès synchronisé à des fonctionnalités externes de fonctionner sans heurt dans un environnement où ces fonctionnalités sont en réalité asynchrones.

L'API JSPI (JavaScript Promise Integration) de WebAssembly a une nouvelle API, disponible dans la version M126 de Chrome. Nous parlons de ce qui a changé, comment l'utiliser avec Emscripten, et quelle est la feuille de route pour JSPI.

JSPI est une API qui permet aux applications WebAssembly utilisant des API séquentielles d'accéder aux API Web qui sont asynchrones. De nombreuses API Web sont conçues en termes d'objets Promise de JavaScript : au lieu d'effectuer immédiatement l'opération demandée, elles renvoient une Promise pour le faire. D'autre part, de nombreuses applications compilées en WebAssembly viennent de l'univers C/C++, qui est dominé par des API bloquant l'appelant jusqu'à achèvement.

Après presque trois ans depuis le document de conception initial et des centaines de CL entretemps, le bac à sable V8 — un bac à sable léger et intégré pour V8 — a atteint un point où il n'est plus considéré comme une fonctionnalité de sécurité expérimentale. Dès aujourd'hui, le bac à sable de V8 est inclus dans le Programme de Récompenses pour les Vulnérabilités de Chrome (VRP). Bien qu'il reste un certain nombre de problèmes à résoudre avant qu'il ne devienne une limite de sécurité robuste, son inclusion dans le VRP constitue une étape importante dans cette direction. Chrome 123 pourrait donc être considéré comme une sorte de version "beta" pour le bac à sable. Cet article de blog est une opportunité de discuter des motivations derrière le bac à sable, de montrer comment il empêche la corruption de mémoire dans V8 de se propager dans le processus hôte, et finalement de démontrer pourquoi il est une étape nécessaire vers la sécurité mémoire.

L'API d'intégration des promesses JavaScript (JSPI) de WebAssembly entre en phase de test origin, avec la version M123 de Chrome. Cela signifie que vous pouvez tester si vous et vos utilisateurs pouvez profiter de cette nouvelle API.

JSPI est une API qui permet à du code dit séquentiel – qui a été compilé en WebAssembly – d'accéder à des API Web qui sont asynchrones. De nombreuses API Web sont conçues en termes de Promises JavaScript : au lieu de réaliser immédiatement l'opération demandée, elles renvoient une Promise pour le faire. Lorsque l'action est finalement réalisée, le gestionnaire de tâches du navigateur déclenche les callbacks liés à la Promise. JSPI s'intègre dans cette architecture permettant à une application WebAssembly d'être suspendue lorsque la Promise est retournée et reprise lorsque celle-ci est résolue.

Vous êtes-vous déjà demandé d’où viennent undefined, true et les autres objets fondamentaux de JavaScript ? Ces objets sont les atomes de tout objet défini par l'utilisateur et doivent exister en premier. V8 les appelle racines immuables immobiles et ils résident dans leur propre tas – le tas en lecture seule. Étant constamment utilisés, un accès rapide est crucial. Et quoi de plus rapide que de deviner correctement leur adresse mémoire au moment de la compilation ?

Bienvenue dans le monde passionnant de V8, où la vitesse n'est pas seulement une caractéristique mais un mode de vie. Alors que nous disons adieu à 2023, il est temps de célébrer les réalisations impressionnantes que V8 a accomplies cette année.

Grâce à des optimisations innovantes en termes de performances, V8 continue de repousser les limites de ce qui est possible dans le paysage toujours en évolution du Web. Nous avons introduit un nouveau compilateur de niveau intermédiaire et mis en œuvre plusieurs améliorations dans l'infrastructure du compilateur de haut niveau, le runtime et le ramasse-miettes, ce qui a entraîné des gains de vitesse significatifs dans tous les domaines.

Dans Chrome M117, nous avons introduit un nouveau compilateur d’optimisation : Maglev. Maglev se situe entre nos compilateurs existants Sparkplug et TurboFan, et joue le rôle d’un compilateur rapide d’optimisation qui génère un code suffisamment performant de manière suffisamment rapide.

Jusqu'en 2021, V8 avait deux principaux niveaux d'exécution : Ignition, l'interpréteur ; et TurboFan, le compilateur d'optimisation de V8 axé sur les performances maximales. Tout le code JavaScript est d'abord compilé en bytecode Ignition, puis exécuté par interprétation. Pendant l'exécution, V8 suit le comportement du programme, y compris les formes et types des objets. Les métadonnées d'exécution et le bytecode sont ensuite utilisés par le compilateur d'optimisation pour générer un code machine performant, souvent spéculatif, qui s'exécute beaucoup plus rapidement que l'interpréteur.