- Die Swift-Community entwickelt die Unterstützung für WebAssembly (Wasm) kontinuierlich weiter und schlägt darauf aufbauend eine langfristige Vision vor
- WebAssembly ist ein Befehlssatz für eine virtuelle Maschine, bei dem Portabilität, Sicherheit und Performance im Vordergrund stehen, und der auf verschiedenen Plattformen ausgeführt werden kann
- Durch die Unterstützung von Wasm in Swift lässt sich Swift in neuen Umgebungen einschließlich des Browsers einsetzen; zugleich erweitert das die Einsatzmöglichkeiten sowohl für Client- als auch Server-Anwendungen
Sicherheits- und Systemschnittstellen-Eigenschaften
- Wasm ist aus Sicherheitsgründen im Vorteil, da es ohne direkten Systemzugriff nur explizit importierte Funktionen ausführen kann
- WASI (WebAssembly System Interface) stellt Standard-APIs bereit, damit Wasm mit dem Host-Betriebssystem interagieren kann
- Swift läuft auf dem Target
wasm32-unknown-wasi auf Basis von WASI libc und ist über C-Interop bereits nutzbar
- Das W3C verwaltet über das Component Model das Typsystem von Wasm und die Kopplung zwischen Modulen integriert
- Mit
wit-tool kann aus Swift-Deklarationen .wit erzeugt werden; die umgekehrte Richtung wird ebenfalls unterstützt
Wichtige Anwendungsfälle
- Swift-Makros lassen sich zu Wasm kompilieren und als Binärdateien verteilen, die überall ausgeführt werden können
- Die Ausführung von SwiftPM-Plugins, Manifests, Makros usw. kann virtualisiert werden, um die Sicherheit zu erhöhen
- Wasm kann per JIT- oder AOT-Kompilierung optimierte Binärdateien erzeugen, wodurch Performance-Verluste minimiert werden
- Als Wasm virtualisierte Swift-Komponenten können ohne separaten Prozess ausgeführt werden, wodurch IPC-Overhead entfällt
Vorgeschlagene Ziele
- Erweiterung des API-Umfangs mit WASI-Unterstützung in der Swift-Standardbibliothek
- Dafür ist der Aufbau einer CI-Umgebung zur Testautomatisierung nötig
- Verbesserung der Cross-Compilation-Werkzeuge
- Versionsverwaltung und Installation des Swift SDK sollen vereinfacht werden
- Integration des Component Model
- Unterstützung dafür, dass die aktuelle WASI-Spezifikation auch in Swift genutzt werden kann
- Verbesserte Interoperabilität mit anderen Wasm-Komponenten
- Ziel ist es, die Nutzung von Wasm-Komponenten aus Swift auf ein Niveau mit C/C++ zu bringen
- Verbesserung der Swift-Debugging-Umgebung auf Wasm
Hinweise zum Debugging
- Das Debugging von Wasm ist eingeschränkt, da es selbst keine Introspection-Funktionen besitzt
- Es gibt zwei wesentliche Ansätze
- Wasm-Runtimes mit Unterstützung für LLDB- und GDB-Protokolle
- In die Wasm-Engine integrierte Debugger
- Browser- und Nicht-Browser-Umgebungen benötigen unterschiedliche Debugging-Ansätze
- Werkzeuge wie Chrome DevTools können DWARF-Informationen nutzen, aber für Swift-Metadaten und die Auswertung von JIT-Ausdrücken ist zusätzliche Integration erforderlich
Multithreading und Concurrency
- In Wasm gibt es derzeit nur atomare Operationen mit sequentieller Konsistenz
- Das Erzeugen von Threads hängt von der Host-Umgebung ab
- Es gibt zwei Threading-Vorschläge:
wasi-threads (bestehender Ansatz, wird von einigen Tools und Runtimes unterstützt)shared-everything-threads (neuer Vorschlag, der künftig zum Standard werden könnte)
- Swift unterstützt
wasm32-unknown-wasi (Single-Thread) und wasm32-unknown-wasip1-threads (Multithread)
- Derzeit wird ein Single-Thread-basierter Swift-Concurrency-Executor verwendet, da libdispatch
wasi-threads nicht unterstützt
64-Bit-Adressraum
- Wasm verwendet standardmäßig einen 32-Bit-Adressraum
- Der 64-Bit-Speichervorschlag (memory64) befindet sich in der Implementierungsphase
- Um dies in Swift zu unterstützen, ist entweder die Zusammenarbeit der WebAssembly-Toolchain oder eine Änderung der Swift-Metadatenstrukturen erforderlich
Gemeinsame Bibliotheken
- Es gibt zwei Ansätze
- Dynamisches Linken im Emscripten-Stil: nicht standardisiert und abhängig von Runtime-Funktionen
- Statisches Linken auf Basis des Component Model: auch ohne spezielle Runtime-Funktionen nutzbar, allerdings ohne Laufzeitladen
- Um gemeinsame Bibliotheken in Swift zu nutzen, muss im PIC-Modus (Position-Independent Code) kompiliert und einem festgelegten Link-Konventionssatz gefolgt werden
1 Kommentare
Swift ist gut, aber kann das aufgegebene Swift wiederbelebt werden..