- Cộng đồng Swift đã liên tục phát triển hỗ trợ WebAssembly (Wasm), và dựa trên đó đã đề xuất một tầm nhìn dài hạn
- WebAssembly là một tập lệnh máy ảo coi trọng tính di động, bảo mật và hiệu năng, có thể chạy trên nhiều nền tảng khác nhau
- Việc hỗ trợ Wasm trong Swift cho phép sử dụng Swift trong những môi trường mới, bao gồm cả trình duyệt, đồng thời mở rộng khả năng ứng dụng ở cả phía client và server
Đặc tính bảo mật và giao diện hệ thống
- Wasm có lợi thế về bảo mật vì chỉ có thể thực thi các hàm được import một cách tường minh mà không có quyền truy cập hệ thống trực tiếp
- WASI (WebAssembly System Interface) cung cấp API tiêu chuẩn để Wasm có thể tương tác với hệ điều hành host
- Swift hoạt động trên target
wasm32-unknown-wasi dựa trên WASI libc và đã có thể sử dụng thông qua C interop
- W3C đang quản lý thống nhất hệ thống kiểu và khả năng liên kết mô-đun của Wasm thông qua Component Model
- Có thể tạo
.wit từ khai báo Swift bằng wit-tool, và cũng hỗ trợ theo chiều ngược lại
Các trường hợp sử dụng chính
- Có thể biên dịch Swift macro sang Wasm để phân phối dưới dạng binary có thể chạy ở bất kỳ đâu
- Có thể ảo hóa việc thực thi SwiftPM plugin, manifest, macro, v.v. để tăng cường bảo mật
- Wasm có thể tạo binary được tối ưu hóa bằng biên dịch JIT hoặc AOT nên giảm thiểu tổn thất hiệu năng
- Các thành phần Swift được ảo hóa bằng Wasm có thể chạy mà không cần tiến trình riêng biệt, loại bỏ overhead IPC
Các mục tiêu được đề xuất
- Mở rộng phạm vi API hỗ trợ WASI trong thư viện chuẩn Swift
- Cần xây dựng môi trường CI cho tự động hóa kiểm thử
- Cải thiện công cụ cross-compilation
- Đơn giản hóa việc quản lý phiên bản và cài đặt Swift SDK
- Tích hợp Component Model
- Hỗ trợ để các đặc tả WASI mới nhất cũng có thể được sử dụng trong Swift
- Nâng cao khả năng interop với các Wasm component khác
- Mục tiêu là đưa trải nghiệm sử dụng Wasm component trong Swift lên ngang mức C/C++
- Cải thiện môi trường debug Swift trên Wasm
Các vấn đề liên quan đến debug
- Khả năng debug của Wasm còn hạn chế, bản thân nó không có chức năng introspection
- Có hai cách tiếp cận chính
- Runtime Wasm hỗ trợ LLDB và giao thức GDB
- Trình gỡ lỗi được tích hợp vào engine Wasm
- Môi trường trình duyệt và môi trường ngoài trình duyệt cần các cách tiếp cận debug khác nhau
- Có thể tận dụng thông tin DWARF trong các công cụ như Chrome DevTools, nhưng vẫn cần tích hợp thêm cho metadata của Swift và khả năng đánh giá biểu thức JIT
Đa luồng và đồng thời
- Hiện tại Wasm chỉ có các phép toán nguyên tử hỗ trợ tính nhất quán tuần tự
- Việc tạo thread phụ thuộc vào môi trường host
- Có hai đề xuất về threading:
wasi-threads (cách hiện có, được hỗ trợ trong một số công cụ và runtime)shared-everything-threads (đề xuất mới, có khả năng trở thành tiêu chuẩn trong tương lai)
- Swift hỗ trợ
wasm32-unknown-wasi (đơn luồng), wasm32-unknown-wasip1-threads (đa luồng)
- Hiện tại, do libdispatch không hỗ trợ wasi-threads, nên đang sử dụng executor Swift Concurrency dựa trên đơn luồng
Không gian địa chỉ 64 bit
- Wasm về cơ bản sử dụng không gian địa chỉ 32 bit
- Đề xuất bộ nhớ 64 bit (memory64) đang ở giai đoạn triển khai
- Để hỗ trợ điều này trong Swift sẽ cần sự phối hợp của toolchain WebAssembly hoặc thay đổi cấu trúc metadata của Swift
Thư viện chia sẻ
- Có hai cách tiếp cận
- Liên kết động kiểu Emscripten: không tiêu chuẩn và phụ thuộc vào chức năng của runtime
- Liên kết tĩnh dựa trên Component Model: có thể dùng mà không cần tính năng đặc biệt của runtime, nhưng không thể nạp lúc chạy
- Để sử dụng thư viện chia sẻ trong Swift, cần biên dịch ở chế độ PIC (Position-Independent Code) và tuân theo quy ước liên kết đã định
1 bình luận
Swift thì tốt đấy, nhưng liệu Swift bị bỏ rơi có thể sống lại được không..