Les équipes du projet WebKit ont annoncé une évolution dans le moteur JavaScript, JavaScriptCore. Cette modification intervient dans le traitement bytecode. Le but est d’introduire un nouveau format de bytecode avec l’espoir d’accélérer et d’optimiser les performances JS. Classiquement, JavaScriptCore est là pour exécuter tous les codes JavaScript. Il doit donc parser le code et générer les bytecodes qui vont bien. 

En arrière-plan, le moteur passe par 4 étapes :

- Low Level Interpreter : on démarre la machine

- Baseline JIT : template du Just In Time

- DFG JIT : optimisation de basse latence (compilateur)

- FTL JIT : optimisation compilateur de plus haut niveau

Pour les équipes WebKit, le bytecode est responsable de 20 % de l’usage mémoire. Bref, comment on peut améliorer la situation ?

L’objectif de ce nouveau format est double :

1 un bytecode plus compact 

2 être plus facilement cachable sur le disque

Avec deux conséquences directes : - consommateur de RAM et des performances en hausse (bytecode + runtime)

Un des gros changements est le fait que le bytecode ne peut plus être directement threadé. L’équipe a opté pour une approche plus cohérente (selon elle) : le bytecode est à la fois stocké et exécuté, chaque instruction peut être encadrée en narrow ou wide. Autre nouveauté, l’apparition d’une table metadata. Là, le moteur va initialiser une table pour recevoir toutes les données associés aux instructions. Cette table est en 2 dimensions. Cette table sert durant le linking du bytecode.

En exécution, comme dit plus haut, l’interpréteur JavaScript fonctionne en thread indirect et non direct. 

Au final, tout ce travail permet une occupation moindre : - 50 % selon les chiffres fournis par WebKit et - 10 % d’usage mémoire sur les très gros sites. 

Pour tous les détails : https://webkit.org/blog/9329/a-new-bytecode-format-for-javascriptcore/