1 pièce(s) jointe(s)
Pourquoi Chrome a activé par défaut le Garbage Collection de WebAssembly (WasmGC) ?
Pourquoi Chrome a activé par défaut le Garbage Collection de WebAssembly ? Avec WasmGC, le ramasse-miettes du langage de programmation n'a plus besoin de faire partie du portage vers Wasm.
Thomas Steiner, défenseur des développeurs chez Google, a écrit que dans Chrome, le Garbage Collection ou ramasse-miettes WebAssembly (WasmGC) est désormais activé par défaut. Dans un billet de blog, il parle des raisons et des conséquences, tout en donnant son avis. Il donne aussi deux exemples de langages de programmation compatibles avec WasmGC en action.
Dans Chrome, le code JavaScript (et WebAssembly) est exécuté par le moteur open source V8 de Google, qui dispose déjà de capacités de Garbage Collection ou ramasse-miettes. "Cela signifie que les développeurs qui utilisent, par exemple, PHP compilé en Wasm, finissent par envoyer une implémentation de garbage collector du langage porté (PHP) au navigateur qui dispose déjà d'un garbage collector", écrit Thomas Steiner, "ce qui est aussi inutile que cela en a l'air".
Mais il s'est ensuite interrogé sur les conséquences pour les langages de programmation de haut niveau (avec leur propre ramasse-miettes intégré) qui sont compilés dans WebAssembly. Le billet de blog comprend deux exemples de langages de programmation compatibles avec WasmGC en action :
- "L'un des premiers langages de programmation qui a été porté sur Wasm grâce à WasmGC est Kotlin sous la forme de Kotlin/Wasm."
- "Les équipes Dart et Flutter de Google préparent également le support de WasmGC. Le travail de compilation de Dart vers Wasm est presque terminé, et l'équipe travaille sur le support d'outils pour livrer des applications web Flutter compilées en WebAssembly."
Voici un extrait du billet de blog :
Il existe deux types de langages de programmation : les langages de programmation à ramasse-miettes et les langages de programmation qui nécessitent une gestion manuelle de la mémoire. Parmi les premiers, on peut citer Kotlin, PHP ou Java. Des exemples du second sont C, C++ ou Rust. En règle générale, les langages de programmation de haut niveau sont plus susceptibles d'avoir une fonction standard de ramasse-miettes. Dans ce billet de blog, l'accent est mis sur ces langages de programmation à collecte de déchets et sur la manière dont ils peuvent être compilés en WebAssembly (Wasm). Mais qu'est-ce que le garbage collection (souvent appelé GC) pour commencer ?
Garbage collection ou ramasse-miettes
En termes simplifiés, l'idée du ramasse-miettes est la tentative de récupérer la mémoire qui a été allouée par le programme, mais qui n'est plus référencée. Cette mémoire est appelée "garbage". Il existe de nombreuses stratégies pour mettre en œuvre le ramasse-miettes. L'une d'entre elles est le comptage de références, dont l'objectif est de compter le nombre de références à des objets en mémoire. Lorsqu'il n'y a plus de références à un objet, celui-ci peut être marqué comme n'étant plus utilisé et donc prêt pour le ramasse-miettes. Le garbage collector de PHP utilise le comptage de références, et l'utilisation de la fonction xdebug_debug_zval() de l'extension Xdebug vous permet de jeter un coup d'œil sous son capot. Considérons le programme PHP suivant.
Code:
1
2
3
4
5
6
7
| <?php
$a= (string) rand();
$c = $b = $a;
$b = 42;
unset($c);
$a = null;
?> |
Le programme affecte un nombre aléatoire converti en chaîne de caractères à une nouvelle variable appelée a. Il crée ensuite deux nouvelles variables, b et c, et leur affecte la valeur de a. Ensuite, il réaffecte b au nombre 42, puis désaffecte c. Enfin, il définit la valeur de a à null. En annotant chaque étape du programme avec xdebug_debug_zval(), vous pouvez voir le compteur de références du garbage collector à l'œuvre.
Code:
1
2
3
4
5
6
7
8
9
10
11
| <?php
$a= (string) rand();
$c = $b = $a;
xdebug_debug_zval('a');
$b = 42;
xdebug_debug_zval('a');
unset($c);
xdebug_debug_zval('a');
$a = null;
xdebug_debug_zval('a');
?> |
L'exemple ci-dessus produira les journaux suivants, où vous verrez comment le nombre de références à la valeur de la variable a diminue après chaque étape, ce qui est logique étant donné la séquence du code. (Votre nombre aléatoire sera bien sûr différent).
Code:
1
2
3
4
5
6
7
8
| a:
(refcount=3, is_ref=0)string '419796578' (length=9)
a:
(refcount=2, is_ref=0)string '419796578' (length=9)
a:
(refcount=1, is_ref=0)string '419796578' (length=9)
a:
(refcount=0, is_ref=0)null |
Citation:
Le comptage de références est utilisé en PHP, mais la plupart des navigateurs modernes n'utilisent pas le comptage de références pour le ramasse-miettes.
Il y a d'autres défis avec le garbage collection, comme la détection des cycles, mais pour cet article, avoir un niveau de compréhension basique du comptage de références est suffisant.
Les langages de programmation sont mis en œuvre dans d'autres langages de programmation
Les langages de programmation sont implémentés dans d'autres langages de programmation. Par exemple, le runtime PHP est principalement implémenté en C. Le code de collecte des déchets de PHP est principalement situé dans le fichier zend_gc.c. La plupart des développeurs installent PHP via le gestionnaire de paquets de leur système d'exploitation. Mais les développeurs peuvent également compiler PHP à partir du code source. Par exemple, dans un environnement Linux, les étapes ./buildconf && ./configure && make construisent PHP pour le système d'exploitation Linux. Mais cela signifie aussi que le runtime PHP peut être compilé pour d'autres runtimes, comme, vous l'avez deviné, Wasm.
Méthodes traditionnelles de portage des langages vers le runtime Wasm
Indépendamment de la plateforme sur laquelle PHP tourne, les scripts PHP sont compilés dans le même bytecode et exécutés par le Zend Engine. Le moteur Zend est un compilateur et un environnement d'exécution pour le langage de script PHP. Il se compose de la machine virtuelle Zend (VM), qui est composée du compilateur Zend et de l'exécuteur Zend. Les langages comme PHP qui sont implémentés dans d'autres langages de haut niveau comme le C ont souvent des optimisations qui ciblent des architectures spécifiques, comme Intel ou ARM, et requièrent un backend différent pour chaque architecture. Dans ce contexte, Wasm représente une nouvelle architecture. Si la VM dispose d'un code spécifique à l'architecture, comme la compilation just-in-time (JIT) ou ahead-of-time (AOT), le développeur implémente également un backend pour JIT/AOT pour la nouvelle architecture. Cette approche a beaucoup de sens car, souvent, la partie principale de la base de code peut simplement être recompilée pour chaque nouvelle architecture.
Étant donné le bas niveau de Wasm, il est naturel d'essayer la même approche : Recompiler le code principal de la VM avec son analyseur, sa bibliothèque, son ramasse-miettes et son optimiseur vers Wasm, et implémenter un backend JIT ou AOT pour Wasm si nécessaire. Cela a été possible depuis le Wasm MVP, et cela fonctionne bien en pratique dans de nombreux cas. En fait, le PHP compilé en Wasm est ce qui fait fonctionner le WordPress Playground.
Cependant, PHP Wasm s'exécute dans le navigateur dans le contexte du langage hôte JavaScript. Dans Chrome, JavaScript et Wasm sont exécutés dans V8, le moteur JavaScript open source de Google qui implémente ECMAScript comme spécifié dans ECMA-262. De plus, V8 dispose déjà d'un ramasse-miettes. Cela signifie que les développeurs qui utilisent, par exemple, PHP compilé en Wasm, finissent par envoyer une implémentation de ramasse-miettes du langage porté (PHP) au navigateur qui dispose déjà d'un ramasse-miettes, ce qui est aussi inutile que cela en a l'air. C'est là que WasmGC entre en jeu.
L'autre problème de l'ancienne approche consistant à laisser les modules Wasm construire leur propre GC au-dessus de la mémoire linéaire de Wasm est qu'il n'y a alors aucune interaction entre le garbage collector de Wasm et le garbage collector construit au sommet du langage compilé dans Wasm, ce qui tend à causer des problèmes tels que des fuites de mémoire et des tentatives de ramasse-miettes inefficaces. Le fait de permettre aux modules Wasm de réutiliser le GC intégré existant permet d'éviter ces problèmes.
Portage de langages de programmation vers de nouveaux moteurs d'exécution avec WasmGC
WasmGC est une proposition du groupe communautaire WebAssembly. L'implémentation actuelle de Wasm MVP n'est capable de traiter que les nombres, c'est-à-dire les entiers et les flottants, dans une mémoire linéaire, et avec la proposition des types de référence en cours de livraison, Wasm peut en outre conserver des références externes. WasmGC ajoute maintenant les types de tas struct et array, ce qui signifie un support pour l'allocation de mémoire non linéaire. Chaque objet WasmGC a un type et une structure fixes, ce qui permet aux machines virtuelles de générer facilement un code efficace pour accéder à leurs champs sans le risque de désoptimisation que présentent les langages dynamiques comme JavaScript. Cette proposition ajoute donc un support efficace pour les langages gérés de haut niveau à WebAssembly, via des types de tas struct et array qui permettent aux compilateurs de langages ciblant Wasm d'intégrer un garbage collector dans la VM hôte. En termes simplifiés, cela signifie qu'avec WasmGC, le portage d'un langage de programmation vers Wasm signifie que le ramasse-miettes du langage de programmation n'a plus besoin de faire partie du portage, mais que le ramasse-miettes existant peut être utilisé.
Pour vérifier l'impact réel de cette amélioration, l'équipe Wasm de Chrome a compilé des versions du benchmark Fannkuch (qui alloue des structures de données au fur et à mesure qu'il fonctionne) en C, Rust et Java. Les binaires C et Rust peuvent peser de 6,1 à 9,6 Ko en fonction des différents drapeaux du compilateur, tandis que la version Java est beaucoup plus petite, avec seulement 2,3 Ko ! C et Rust n'incluent pas de garbage collector, mais ils intègrent toujours malloc/free pour gérer la mémoire, et la raison pour laquelle Java est plus petit ici est qu'il n'a pas besoin d'intégrer de code de gestion de la mémoire du tout. Ce n'est qu'un exemple spécifique, mais il montre que les binaires WasmGC ont le potentiel d'être très petits, et ce avant même tout travail significatif sur l'optimisation de la taille.
Langage de programmation porté par WasmGC en action
- Kotlin Wasm: L'un des premiers langages de programmation qui a été porté sur Wasm grâce à WasmGC est Kotlin sous la forme de Kotlin/Wasm.
- Dart and Flutter : Les équipes Dart et Flutter de Google préparent également la prise en charge de WasmGC. Le travail de compilation Dart-to-Wasm est presque terminé, et l'équipe travaille sur le support d'outils pour livrer des applications web Flutter compilées en WebAssembly.
Des démos concernant ces deux langages de programmation porté par WasmGC en action sont disponible dans la source.
Source : Thomas Steiner
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: État de WebAssembly en 2023: Rust est le langage le plus utilisé. Les utilisateurs veulent une meilleure intégration hors navigateur, les threads et le garbage collection sont en phase de finalisation
:fleche: V8, le moteur JavaScript de Google, est désormais plus léger avec 22 % de charge de mémoire en moins
:fleche: Une enquête sur les technologies web indique que WebAssembly serait surestimé, la quantité de code wasm dans les pages Web représente 0,06 % sur ordinateur de bureau et 0,04 % sur mobile
