Quelques expériences de Dart avec LLVM donnent des résultats prometteurs
qui pourraient être améliorés avec des optimisations du ramasse-miettes ajouté

Dart est l’un des nombreux langages de programmation développés par Google. Il avait pour objectif premier de remplacer JavaScript dans les navigateurs (certaines versions préliminaires de Chrome avaient une machine virtuelle Dart), puis ses objectifs ont évolué pour être plus consensuels : un remplaçant potentiel de Java, mais avec toujours en tête l’idée de générer du code JavaScript très efficace. Le langage a donc un système de type dynamique et optionnel (les types des variables ne sont connus qu’à l’exécution), mais en limitant ses capacités dynamiques à la portion congrue (pas de fonction eval, pas d’ajout de propriétés à un objet après sa création).

Des ingénieurs de Google ont tenté une expérience : remplacer la machine virtuelle derrière l’implémentation standard de Dart par LLVM et une compilation avant l’exécution, voir si cela permettrait d’améliorer la performance à l’exécution, notamment — LLVM est l’infrastructure de compilation derrière Clang, notamment. La tâche n’est pas aisée a priori : la machine virtuelle de Dart effectue déjà un gros travail de compilation du code à la volée avec des optimisations. LLVM n’est pas non plus prévu pour des langages avec ramasse-miettes, qui perturbent ses routines d’optimisation du code.

De manière générale, une idée reçue est que l’implémentation d’un langage a droit à soit un ramasse-miette précis et efficace, soit un haut niveau d’optimisation du code. En effet, le ramasse-miette parcourt régulièrement les pointeurs sur de la mémoire allouée pour vérifier qu’elle est toujours utile ; après une passe d’optimisation, le code a tellement changé d’apparence qu’il est impossible de s’y retrouver. Une technique pour contourner le problème est de stocker les pointeurs dans une zone particulière, mais cela met en échec bon nombre d’optimisations possibles du code.

Il y a peu, LLVM a intégré une nouvelle fonctionnalité expérimentale, les points d’état, qui sert justement à laisser le compilateur effectuer ses optimisations sans perturber le fonctionnement d’un ramasse-miettes. Le principe est de marquer explicitement les modifications du code au ramasse-miettes, de telle sorte que, en cas de déplacement d’un objet en mémoire, tous les pointeurs concernés peuvent être mis à jour (plus d’informations dans la documentation de LLVM).

L’expérience s’est basée sur le code de Dartino, qui utilisait déjà LLVM pour optimiser du code Dart. Cependant, Dartino n’utilisait pas de ramasse-miettes, cette implémentation se limitait à lamentablement planter en cas de manque de mémoire. L’opération principale a été d’ajouter un ramasse-miettes à l’exécution et de le faire travailler de pair avec les optimisations. (Voir les détails d’implémentation.) Les résultats sont prometteurs : la performance est similaire à Flutter, qui a le même objectif (compiler du code Dart), tout en utilisant une infrastructure plus générique. Très peu de travail spécifique à Dart a été requis côté LLVM — certaines modifications pourraient augmenter la performance drastiquement, cependant. Des améliorations du ramasse-miettes pourraient aussi améliorer fortement la situation, les algorithmes actuellement utilisés pour cette expérience n’étant pas au même niveau que Flutter.


Globalement, l’objectif de cette « petite » expérience est atteint : oui, il est possible de mélanger LLVM, des optimisations très pointues du code, avec un ramasse-miettes, avec une performance tout à fait respectable.

Source : Dart-on-LLVM.