Proposition de vision pour la prise en charge de WebAssembly dans Swift

• La communauté Swift développe de manière continue la prise en charge de WebAssembly (Wasm) et propose, sur cette base, une vision à long terme
• WebAssembly est un jeu d’instructions pour machine virtuelle axé sur la portabilité, la sécurité et les performances, exécutable sur de nombreuses plateformes
• La prise en charge de Wasm dans Swift permettrait d’utiliser Swift dans de nouveaux environnements, y compris le navigateur, et d’élargir ses usages aussi bien pour les applications client que serveur

Caractéristiques de sécurité et d’interface système

• Wasm est avantageux pour la sécurité, car il ne peut exécuter que des fonctions importées explicitement, sans accès direct au système
• WASI (WebAssembly System Interface) fournit des API standard permettant à Wasm d’interagir avec l’OS hôte
• Swift fonctionne déjà sur la cible wasm32-unknown-wasi sur la base de WASI libc, avec une utilisation possible via l’interop C
• Le W3C gère de façon unifiée le système de types et l’interconnexion des modules Wasm via le Component Model
  • Avec wit-tool, il est possible de générer des fichiers .wit à partir de déclarations Swift, et l’inverse est également pris en charge

Principaux cas d’usage

• Les macros Swift peuvent être compilées en Wasm et distribuées comme des binaires exécutables partout
• L’exécution des plugins SwiftPM, des manifestes, des macros, etc. peut être virtualisée pour renforcer la sécurité
• Wasm peut produire des binaires optimisés via une compilation JIT ou AOT, ce qui permet de minimiser la perte de performances
• Des composants Swift virtualisés avec Wasm peuvent s’exécuter sans processus séparé, supprimant ainsi la surcharge IPC

Objectifs proposés

1. Étendre le périmètre des API prises en charge par WASI dans la bibliothèque standard Swift
   • Il est nécessaire de mettre en place un environnement CI pour l’automatisation des tests
2. Améliorer les outils de cross-compilation
   • Simplifier la gestion des versions et l’installation du Swift SDK
3. Intégration du Component Model
   • Prendre en charge les dernières spécifications WASI afin qu’elles puissent aussi être utilisées dans Swift
4. Améliorer l’interop avec d’autres composants Wasm
   • L’objectif est d’offrir dans Swift une expérience d’utilisation des composants Wasm équivalente à celle du C/C++
5. Améliorer l’environnement de débogage de Swift sur Wasm

Éléments liés au débogage

• Le débogage de Wasm est limité et ne dispose pas nativement de fonctions d’introspection
• Il existe deux grandes approches
  1. Un runtime Wasm prenant en charge LLDB et le protocole GDB
  2. Un débogueur intégré au moteur Wasm
• Les environnements navigateur et hors navigateur nécessitent des approches de débogage différentes
• Des outils comme Chrome DevTools peuvent exploiter les informations DWARF, mais l’intégration des métadonnées Swift et de l’évaluation d’expressions JIT nécessite un travail supplémentaire

Multithreading et concurrence

• Wasm ne dispose actuellement que d’opérations atomiques avec cohérence séquentielle
• La création de threads dépend de l’environnement hôte
• Deux propositions de threading existent :
  • wasi-threads (approche existante, prise en charge par certains outils et runtimes)
  • shared-everything-threads (nouvelle proposition, susceptible de devenir un standard à l’avenir)
• Swift prend en charge wasm32-unknown-wasi (mono-thread) et wasm32-unknown-wasip1-threads (multi-thread)
• Actuellement, comme libdispatch ne prend pas en charge wasi-threads, un exécuteur Swift Concurrency mono-thread est utilisé

Espace d’adressage 64 bits

• Wasm utilise par défaut un espace d’adressage 32 bits
• La proposition de mémoire 64 bits (memory64) est en cours d’implémentation
• Pour la prendre en charge dans Swift, il faut soit la coopération de la toolchain WebAssembly, soit une modification des structures de métadonnées Swift

Bibliothèques partagées

• Deux approches existent
  1. Édition de liens dynamique de style Emscripten : non standard et dépendante de fonctionnalités du runtime
  2. Édition de liens statique basée sur le Component Model : utilisable sans fonctionnalités spécifiques du runtime, mais sans chargement à l’exécution
• Pour utiliser des bibliothèques partagées dans Swift, il faut compiler en mode PIC (Position-Independent Code) et suivre une convention de linkage définie

[kandk]

Swift, c’est bien, mais est-ce que Swift, laissé à l’abandon, pourra renaître ?..