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.
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 : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7 <?php $a= (string) rand(); $c = $b = $a; $b = 42; unset($c); $a = null; ?>
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 : S�lectionner tout - Visualiser dans une fen�tre � part
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'); ?>
Code : S�lectionner tout - Visualiser dans une fen�tre � part
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)nullIl 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.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.
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 ?
Quel est votre avis sur le sujet ?
Voir aussi :
�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
V8, le moteur JavaScript de Google, est d�sormais plus l�ger avec 22 % de charge de m�moire en moins
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
Partager