Tous les six semaines, nous créons une nouvelle branche de V8 dans le cadre de notre processus de publication. Chaque version est issue directement de la branche principale Git de V8, juste avant une étape importante Beta de Chrome. Aujourd’hui, nous sommes ravis d’annoncer notre toute dernière branche, V8 version 7.7, actuellement en version bêta avant sa publication coordonnée avec Chrome 77 Stable dans quelques semaines. V8 v7.7 regorge de nouvelles fonctionnalités destinées aux développeurs. Ce billet présente un aperçu de certains points forts en prévision de sa mise en production.

WebAssembly est normalement compilé à partir d’un langage source, ce qui signifie que les développeurs ont besoin d’outils pour l’utiliser. C’est pourquoi l’équipe de V8 travaille sur des projets open-source pertinents comme LLVM, Emscripten, Binaryen et WABT. Ce post décrit certains des travaux que nous avons effectués sur Emscripten et LLVM, ce qui permettra bientôt à Emscripten de passer par défaut au backend LLVM WebAssembly — veuillez le tester et signaler tout problème !

Toutes les six semaines, nous créons une nouvelle branche de V8 dans le cadre de notre processus de sortie. Chaque version est dérivée du master Git de V8 juste avant une étape Beta de Chrome. Aujourd’hui, nous sommes heureux d’annoncer notre nouvelle branche, V8 version 7.6, actuellement en version beta jusqu’à sa sortie en coordination avec Chrome 76 Stable dans plusieurs semaines. V8 v7.6 est rempli de nombreuses nouveautés pour les développeurs. Cet article donne un aperçu de certains points forts en prévision de la sortie.

Il y a un dicton parmi les développeurs qui dit que le code le plus rapide est celui qui ne s’exécute pas. De même, le code qui se compile le plus rapidement est celui qui n’a pas besoin d’être compilé. La mise en cache du code WebAssembly est une nouvelle optimisation dans Chrome et V8 qui vise à éviter la compilation du code en mettant en cache le code natif produit par le compilateur. Nous avons écrit sur comment Chrome et V8 mettent en cache le code JavaScript dans le passé, et les meilleures pratiques pour tirer parti de cette optimisation. Dans cet article, nous décrivons le fonctionnement de la mise en cache du code WebAssembly dans Chrome et comment les développeurs peuvent en tirer parti pour accélérer le chargement des applications avec de grands modules WebAssembly.

Toutes les six semaines, nous créons une nouvelle branche de V8 dans le cadre de notre processus de publication. Chaque version est issue du dépôt maître Git de V8 immédiatement avant une étape bêta de Chrome. Aujourd’hui, nous sommes ravis d’annoncer notre nouvelle branche, version 7.5 de V8, qui est en phase bêta jusqu’à sa publication en coordination avec Chrome 75 Stable dans quelques semaines. V8 v7.5 regorge d’éléments intéressants pour les développeurs. Ce billet fournit un aperçu de certains des points forts en prévision de la publication.

La spécification de l'API d'internationalisation ECMAScript (ECMA-402, ou Intl) fournit des fonctionnalités clés spécifiques à chaque langue, comme le formatage des dates, des nombres, la sélection des formes plurielles et le classement. Les équipes Chrome V8 et Google Internationalization ont collaboré pour ajouter des fonctionnalités à l'implémentation ECMA-402 de V8, tout en nettoyant les dettes techniques et en améliorant les performances ainsi que l'interopérabilité avec d'autres navigateurs.

Le 3 janvier 2018, Google Project Zero et d'autres ont révélé les trois premières failles d'une nouvelle classe de vulnérabilités affectant les CPU utilisant l'exécution spéculative, nommées Spectre et Meltdown. En exploitant les mécanismes d'exécution spéculative des CPU, un attaquant pouvait temporairement contourner les vérifications implicites et explicites de sécurité dans le code empêchant les programmes de lire des données non autorisées en mémoire. Bien que la spéculation des processeurs ait été conçue comme un détail microarchitectural, invisible au niveau architectural, des programmes soigneusement conçus pouvaient lire des informations non autorisées lors de la spéculation et les divulguer via des canaux auxiliaires comme le temps d'exécution d'un fragment de programme.

Voici la deuxième partie de notre série expliquant comment V8 analyse JavaScript aussi rapidement que possible. La première partie expliquait comment nous avons rendu le scanner de V8 rapide.

L’analyse syntaxique est l’étape où le code source est converti en une représentation intermédiaire qui sera consommée par un compilateur (dans V8, le compilateur de bytecode Ignition). L’analyse et la compilation se déroulent sur le chemin critique du démarrage de la page web, et toutes les fonctions envoyées au navigateur ne sont pas immédiatement nécessaires lors du démarrage. Même si les développeurs peuvent différer ce code avec des scripts asynchrones et différés, cela n’est pas toujours possible. De plus, de nombreuses pages web incluent du code utilisé uniquement par certaines fonctionnalités qui peuvent ne pas être accessibles du tout par un utilisateur au cours de l’exécution individuelle de la page.

La mise en cache de code (également appelée mise en cache de bytecode) est une optimisation importante dans les navigateurs. Elle réduit le temps de démarrage des sites web fréquemment visités en mettant en cache le résultat de l’analyse et de la compilation. La plupart des navigateurs populaires implémentent une forme de mise en cache de code, et Chrome ne fait pas exception. En effet, nous avons déjà écrit et parlé de la façon dont Chrome et V8 mettent en cache le code compilé.