- Swiftコミュニティは WebAssembly(Wasm) のサポートを継続的に開発しており、これを基に長期的なビジョンを提案
- WebAssemblyは 移植性、セキュリティ、性能 を重視する 仮想マシン命令セット であり、さまざまなプラットフォームで実行可能
- SwiftでWasmをサポートすると ブラウザを含む新しい環境 でSwiftを利用できるようになり、クライアント/サーバーアプリケーション の両方で活用の可能性が広がる
セキュリティとシステムインターフェースの特性
- Wasmは 直接的なシステムアクセスなしに、明示的にインポートされた関数のみ実行 できるため、セキュリティ面で有利
- WASI(WebAssembly System Interface) は、WasmがホストOSと相互作用できるように標準APIを提供
- Swiftは
wasm32-unknown-wasi ターゲットでWASI libcを基盤として動作し、Cインターロップを通じてすでに利用可能
- W3Cは Component Model を通じてWasmの型システムとモジュール連携を統合的に管理
wit-tool を通じてSwift宣言から .wit を生成でき、逆方向もサポート
主なユースケース
- Swiftマクロ をWasmにコンパイルし、どこでも実行可能なバイナリとして配布可能
- SwiftPMプラグイン、マニフェスト、マクロなどの実行を 仮想化してセキュリティを強化
- WasmはJITまたはAOTコンパイルによって最適化されたバイナリを生成できるため、性能低下を最小化
- Wasmで仮想化されたSwiftコンポーネントは 別プロセスなしで実行可能 で、IPCオーバーヘッドを排除
提案された目標
- Swift標準ライブラリのWASI対応API範囲の拡大
- クロスコンパイルツールの改善
- Swift SDKのバージョン管理とインストールの簡素化
- Component Modelの統合
- 最新のWASI仕様をSwiftでも使えるようにサポート
- 他のWasmコンポーネントとのインターロップ向上
- SwiftでWasmコンポーネントを利用する体験をC/C++と同等にすることが目標
- Wasm上でのSwiftデバッグ環境の改善
デバッグ関連事項
- Wasmのデバッグには制約があり、独自のintrospection機能はない
- 2つの主要なアプローチが存在
- LLDBとGDBプロトコルをサポートするWasmランタイム
- Wasmエンジンに組み込まれたデバッガ
- ブラウザ環境と非ブラウザ環境では異なるデバッグ手法が必要
- Chrome DevToolsなどのツールでDWARF情報を活用できるが、SwiftメタデータやJIT式評価機能については追加の統合が必要
マルチスレッドと並行性
- Wasmには現在 逐次一貫性をサポートする原子演算 のみ存在
- スレッド生成は ホスト環境に依存
- 2つのスレッド化提案が存在:
wasi-threads （既存方式、一部のツールおよびランタイムでサポート）shared-everything-threads （新しい提案、今後標準になる可能性あり）
- Swiftは
wasm32-unknown-wasi （シングルスレッド）、wasm32-unknown-wasip1-threads （マルチスレッド）をサポート
- 現在は libdispatchがwasi-threadsをサポートしていないため、シングルスレッドベースのSwift Concurrencyエグゼキュータ を使用中
64ビットアドレス空間
- Wasmは基本的に 32ビットアドレス空間 を使用
- 64ビットメモリ提案(memory64) は実装段階にある
- Swiftでこれをサポートするには WebAssemblyツールチェーンの協力 または Swiftメタデータ構造の変更 が必要
共有ライブラリ
- 2つの方式が存在
- Emscriptenスタイルの動的リンク: 非標準であり、ランタイム機能に依存
- Component Modelベースの静的リンク: ランタイムの特殊機能なしでも利用可能だが、ランタイムロードは不可
- Swiftで共有ライブラリを利用するには PIC(Position-Independent Code) モードでコンパイルし、定められたリンク規約 に従う必要がある
1件のコメント
Swift は良いけど、見捨てられた Swift がまた息を吹き返すことはできるのでしょうか..