WASM 3.0 hoàn thiện

• Tiêu chuẩn Wasm 3.0 được công bố chính thức, bao gồm các tính năng quy mô lớn đã được chuẩn bị trong 6–8 năm
• Các tính năng như không gian địa chỉ 64-bit, garbage collection, typed reference, tail call, xử lý ngoại lệ giúp việc biên dịch các ngôn ngữ bậc cao sang Wasm trở nên dễ dàng hơn
• Những tính năng cốt lõi mới hỗ trợ ứng dụng hiệu năng cao, runtime cho nhiều ngôn ngữ khác nhau, tính an toàn và khả năng mở rộng
• Phù hợp với các trường hợp ngoài môi trường web, cả trong hệ sinh thái phi web nơi cần xử lý dung lượng và tập dữ liệu lớn hơn
• Đã được hỗ trợ trên các trình duyệt web lớn và cũng sắp hoàn thiện trên các engine độc lập như Wasmtime, qua đó củng cố thêm vị thế của Wasm như một nền tảng thực thi đa dụng

---

Tổng quan phát hành Wasm 3.0

• Phiên bản 3.0 của tiêu chuẩn WebAssembly được phát hành vào ngày 17/09/2025
  • Đây là bản cập nhật lớn sau 3 năm kể từ phiên bản 2.0 (hoàn tất năm 2022), vốn đã giới thiệu lệnh vector, thao tác bulk memory, nhiều giá trị trả về và các kiểu tham chiếu đơn giản
  • Nhóm cộng đồng và nhóm công tác của W3C tiếp tục phát triển chuẩn này, và bản phát hành lần này là một thay đổi quy mô đáng kể bao gồm các tính năng lớn đã được chuẩn bị trong 6–8 năm
  • Wasm vẫn giữ tinh thần của một ngôn ngữ cấp thấp, đồng thời tăng cường hệ thống bộ nhớ và kiểu dữ liệu để hỗ trợ tốt hơn cho việc biên dịch ngôn ngữ bậc cao
• Các tính năng được phát triển sau phiên bản 2.0 đã hoàn tất và trở thành tiêu chuẩn Live, với mức hỗ trợ ngày càng mở rộng trên trình duyệt web và các engine độc lập
  • Có thể theo dõi tình trạng hỗ trợ của từng engine tại trang trạng thái tính năng Wasm
  • Bản này là phiên bản đầu tiên được tạo bằng chuỗi công cụ mới SpecTec, giúp cải thiện độ tin cậy

Các thay đổi chính và tính năng mới

• Không gian địa chỉ 64-bit
  • Có thể khai báo bộ nhớ và bảng bằng kiểu i64
  • Không gian địa chỉ của ứng dụng Wasm có thể mở rộng từ khoảng 4GB lên tới giới hạn vật lý (về lý thuyết là 16 exabyte)
  • Trên web, giới hạn 16GB được áp dụng, nhưng trong hệ sinh thái phi web điều này hữu ích cho việc hỗ trợ ứng dụng và tập dữ liệu quy mô lớn
• Đa bộ nhớ
  • Có thể khai báo và truy cập trực tiếp nhiều đối tượng bộ nhớ trong một module duy nhất
  • Có thể dùng cho nhiều mục đích như hợp nhất module, tách biệt không gian địa chỉ, buffering, bảo mật
  • Các công cụ liên kết tĩnh như wasm-merge giờ có thể áp dụng cho mọi module Wasm
• Garbage collection (GC)
  • Ngoài linear memory, còn hỗ trợ vùng lưu trữ do runtime Wasm tự động quản lý
  • Trình biên dịch có thể trực tiếp khai báo bố cục dữ liệu như kiểu struct/array và các số nguyên unboxed
  • Chỉ cung cấp các khối xây dựng cơ bản cho quản lý bộ nhớ; còn hệ thống đối tượng bậc cao hoặc closure có thể được thiết kế riêng tùy theo ngôn ngữ triển khai
• Typed reference
  • Hệ thống kiểu của Wasm được mở rộng để mô tả chính xác hơn hình dạng của giá trị heap và tham chiếu hàm
  • Hỗ trợ subtyping, đệ quy kiểu, và với lệnh call_ref mới có thể gọi hàm gián tiếp an toàn mà không cần kiểm tra kiểu lúc chạy
• Tail call
  • Hỗ trợ cấu trúc tail call trả về ngay mà không dùng thêm không gian stack của hàm hiện tại
  • Có thể được dùng cho ngôn ngữ hàm hoặc các tối ưu hóa bên trong runtime
• Xử lý ngoại lệ
  • Đưa vào một hệ thống xử lý ngoại lệ native bên trong Wasm
  • Hỗ trợ khai báo thẻ ngoại lệ và payload, bắt ngoại lệ có chọn lọc, cùng trình xử lý ngoại lệ theo khối
  • Có thể cải thiện tính di động và hiệu năng mà không cần dùng các cách vòng qua JS kém hiệu quả như trước
• Lệnh vector relaxed
  • Để thích ứng với khác biệt phần cứng của các lệnh SIMD, chuẩn cung cấp biến thể relaxed cho phép một số chi tiết hành vi của lệnh do từng implementation tự quyết định
  • Nhờ đó có thể thực hiện nhiều tối ưu hóa khác nhau trong phạm vi các hành vi hợp lệ
• Deterministic profile
  • Ngay cả trong các tình huống mà kết quả của cùng một lệnh vốn có thể phi xác định (như phép toán dấu chấm động, relaxed SIMD), chuẩn vẫn định nghĩa cách thực thi mang tính quyết định giữa các nền tảng
  • Điều này giúp đảm bảo khả năng tái lập và tính di động cho blockchain, hệ thống có thể phát lại và các trường hợp tương tự
• Cú pháp custom annotation
  • Bổ sung cú pháp annotation mà con người có thể đọc và viết trực tiếp trong mã nguồn
  • Chuẩn không tự diễn giải chúng, nhưng có thể được dùng cho các tiêu chuẩn hoặc phần mở rộng trong tương lai

Kết nối với JavaScript và khả năng tương thích

• JS string builtins
  • Có thể truyền và thao tác giá trị chuỗi của JS trong Wasm dưới dạng externref
  • Bằng cách import các hàm built-in mới, Wasm có thể trực tiếp sử dụng các chuỗi JS bên ngoài từ bên trong module

Giá trị và triển vọng của Wasm 3.0

• Cung cấp nền tảng thiết yếu cho biên dịch nhắm mục tiêu Wasm của các ngôn ngữ lập trình nâng cao
• Các ngôn ngữ chính như Java, OCaml, Scala, Kotlin, Scheme, Dart cũng đã bắt đầu tích cực tận dụng tính năng GC

Tình hình xây dựng đặc tả và triển khai

• Wasm 3.0 là tiêu chuẩn đầu tiên được xây dựng bằng chuỗi công cụ mới SpecTec
• Hầu hết các trình duyệt web lớn đã hỗ trợ Wasm 3.0, và các engine độc lập như Wasmtime cũng sắp hoàn tất hỗ trợ
• Có thể kiểm tra tình trạng hỗ trợ của từng engine tại trang Wasm feature status

[coremaker]

Liệu rồi cũng sẽ xuất hiện những nỗ lực nhằm tạo ra một DB trong bộ nhớ chứ?

[GN⁺]

Ý kiến trên Hacker News

• Điều thực sự đáng mong đợi là 64-bit sẽ trở thành mặc định của đặc tả, nhất là với các web app như trình chỉnh sửa video trực tuyến, hiện vẫn bị rất nhiều ràng buộc vì giới hạn 32-bit, Figma cũng đang trực tiếp gặp những hạn chế này; một điều tôi tò mò là liệu giới hạn bộ nhớ có thể địa chỉ hóa theo từng tab trên thiết bị di động có còn được giữ nguyên hay không, vì thường nó do OS định nghĩa nên có thể không gắn trực tiếp với không gian 32-bit

  • Tôi nghi ngờ việc những ứng dụng như video editor lại chui vào trình duyệt tài liệu có thực sự đúng đắn không; khá tiếc khi đã có các hệ điều hành native được làm tốt nhưng giờ chẳng mấy ai dùng nữa; nếu cần một máy ảo còn mạnh hơn cả mức cô lập mà tiến trình hệ điều hành hiện có cung cấp, tôi nghĩ thiết kế hẳn một abstraction phù hợp mục đích sẽ thành thật hơn; cảm giác như đang cố cải tạo một trình đọc tài liệu đơn giản thành công cụ dựng video

  • Tiếc là tính năng Memory64 có penalty hiệu năng khá lớn; ở 32-bit trước đây, runtime thường cấp phát luôn toàn bộ 4GB nên gần như không cần kiểm tra biên, còn với 64-bit thì phải tự kiểm tra biên trực tiếp; nếu thật sự cần hơn 4GB bộ nhớ thì đành phải dùng thôi

  • Tôi cũng trông đợi GC, reference types và JS string API được đưa vào; lâu rồi mới thấy một chữ J đáng mừng, không biết dạo này cậu sống sao rồi

  • Việc web app bị chặn ở giới hạn 4GiB bộ nhớ nghe có vẻ là lẽ đương nhiên; cảm giác như đang sống trong thời đại mà đọc email thôi cũng cần tối thiểu 512GiB

• Việc thêm garbage collection thật sự rất thú vị; trước đây trong Wasm không thể truy cập trực tiếp stack nên các cách tiếp cận GC truyền thống như stack scanning là bất khả thi; nhờ vậy nó vẫn giữ được tính chất của ngôn ngữ low-level, đồng thời có thể mô tả rõ layout bộ nhớ bằng struct, array type, unboxed tagged int, còn việc cấp phát và quản lý vòng đời thì để Wasm xử lý; chỉ đến thế thôi mà đã thấy rất ấn tượng

  • Việc GC được đưa vào trong khi vẫn hỗ trợ cả môi trường không có GC là điều khá mới mẻ; điểm này giống với ngôn ngữ D (D hỗ trợ biên dịch và chạy nhanh cho cả môi trường có GC lẫn không GC); nhân tiện, giờ trình biên dịch Dlang là LDC cũng đã có thể sinh Wasm Generating WebAssembly with LDC

  • Tôi tò mò liệu thay đổi này có giúp thu nhỏ được kích thước của đối tượng WebAssembly.Memory hay không; đây là vấn đề rất quan trọng vì dù giải phóng bộ nhớ rồi thì nó vẫn còn bị giữ ở phía trình duyệt vấn đề 1 vấn đề 2

• Tôi tò mò bao giờ WASM mới có thể đụng trực tiếp vào DOM; điều này có vẻ như từng là mục tiêu cốt lõi ban đầu của WASM, nhưng giờ nó lại giống một con quái vật riêng gần như không liên quan tới web; không biết đến bao giờ mới có thể không cần dùng JavaScript nữa

  • Tôi mong phần này cùng với truy cập multithread sẽ được hỗ trợ tử tế; tôi muốn viết app bằng Rust, biên dịch sang wasm rồi gọi thẳng như dưới đây:

    Với những chỗ như web app hiệu năng cao hoặc browser extension thì vấn đề bộ nhớ và hiệu năng là rất thật, nên việc này sẽ cực kỳ hữu ích; nếu là app dựa trên wasm thì còn có thể bỏ qua v8 và dùng trực tiếp engine như wasmer; tôi nghĩ việc công nghệ web được dùng cho desktop app kiểu Electron là vì desktop API quá tệ và không có tính portable; nếu hỗ trợ native cho WASM mạnh hơn thì các app như Slack, VSCode, Discord có thể nhẹ hơn nhiều

  • Ngay lúc này cũng có thể truy cập DOM từ chương trình WASM, chỉ là phải đi qua JS API hiện có; trước đây từng có thảo luận về API riêng cho WASM nhưng vì phát sinh quá nhiều nhược điểm nên cuối cùng đã bị hủy bỏ

  • Tôi đang chờ xem có ngôn ngữ frontend nào được thiết kế tốt xuất hiện không; nhưng cũng tự hỏi việc phải đi qua JS wrapper khi truy cập DOM có thật sự kém hiệu quả đến thế không; phần lớn code vốn đã không hiệu quả rồi, nên phần overhead phát sinh từ đây có lẽ trên thực tế cũng không quá nổi bật

  • Nếu bạn nghĩ JavaScript có vấn đề thì sang phía DOM bạn sẽ thấy còn tệ hơn

  • Khi nắm giữ tham chiếu DOM thì sẽ thành chuyện khá tricky vì có thể nhìn trực tiếp vào các đối tượng có garbage collection; theo mô hình bảo mật của web JavaScript thì không được phép nhìn vào bên trong GC, nhưng nếu WASM giữ pointer tới DOM thì xử lý chuyện đó thế nào sẽ là vấn đề; sau khi GC được đưa vào bài bản thì chủ đề này có thể được bàn lại, nhưng với WASM không có GC thì có vẻ gần như không có lời giải

• Tôi không theo dõi phát triển WASM khoảng một năm, giờ mới biết là nó đã chuyển sang mô hình phát hành theo phiên bản; trước đây tôi nghĩ nhiều tính năng sẽ cứ để ở dạng tùy chọn, nhưng giờ có vẻ là muốn gọi tương thích với một phiên bản nào đó (như WASM 3.0) thì mọi implementation đều phải hỗ trợ tất cả tính năng; tôi tò mò runtime non-browser nào sẽ là bên thứ hai hỗ trợ đầy đủ 3.0, có lẽ là wasmtime (loại deno vì nó dựa trên v8); GC đặc biệt có cảm giác là tính năng rất tricky; không biết bản phát hành 3.0 này liên hệ thế nào với mô hình "evergreen" trước đây; evergreen là kiểu cứ cập nhật liên tục các bản thảo tiêu chuẩn, còn bản chính thức cuối cùng thì để riêng; hiện tại Candidate Recommendation Draft mới nhất trên thực tế được xem như tiêu chuẩn tình hình các tính năng wasm tin về wasm 2.0 bản thảo tiêu chuẩn mới nhất

  • wasmtime thực ra đã hỗ trợ toàn bộ các tính năng chính của wasm 3.0; GC đã được đồng nghiệp của tôi là Nick Fitzgerald triển khai từ vài năm trước, tail call thì năm ngoái Jamey Sharp và Trevor Elliott đã triển khai đầy đủ phạm vi (không giới hạn chữ ký, không cần trampoline); exception handling cũng đã xong và sắp ra bản phát hành chính thức; có thể xem bản phát hành "3.0" này là tín hiệu rằng các engine thực chất đã chuẩn bị sẵn từng tính năng từ trước; tôi là maintainer của wasmtime và Cranelift

  • Wizard là công cụ phục vụ nghiên cứu nhưng có hỗ trợ đầy đủ Wasm 3.0; chỉ là nó chỉ có interpreter và baseline compiler, không có compiler tối ưu hóa như v8 hay wasmtime, nên tốc độ tự thân thì chậm

  • Có vẻ việc quản lý phiên bản sẽ giống cách JavaScript nói về feature set, tức là sẽ mô tả theo tập tính năng mà từng runtime hỗ trợ; tôi tò mò cơ chế feature discovery trong wasm vận hành ra sao

• Tôi rất mừng vì có thêm hỗ trợ GC; trước đây trong WASM không thể truy cập trực tiếp stack nên về cơ bản không thể hiện thực GC kiểu stack scanning truyền thống

• Tôi cảm thấy cộng đồng WebAssembly cần quan tâm hơn đến trải nghiệm nhà phát triển (DX); tôi từng tự viết một compiler nhắm tới Wasm và thấy khá bất tiện; tôi nghĩ đây là một ngôn ngữ có ngữ nghĩa khá chặt chẽ, nhưng khi tạo Wasm bằng Binaryen.js thì lại không có cảm giác đang target một tập instruction thật sự rõ ràng; có lẽ do chính Binaryen và tài liệu còn thiếu; điểm an ủi là viết các snippet Wasm text khá vui trình biên dịch jasmine wasm

  • Binaryen mang nhiều di sản từ thời Wasm còn là AST; các tính năng mới khó ép vừa vào mô hình cũ; compiler của chúng tôi tự định nghĩa cấu trúc dữ liệu riêng cho biểu diễn Wasm trừu tượng, và mặc định khi compile thì xuất ra .wasm, còn lúc debug thì xuất ra .wat; tôi thấy khá trực quan nên nghĩ tập instruction vẫn ổn Scala.js wasm backend

  • Tôi cũng từng dùng Binaryen từ TypeScript và có cảm giác bí bách tương tự; sau đó chuyển sang wasm-tools viết bằng Rust thì trải nghiệm tốt hơn hẳn

  • Tôi tò mò cụ thể phần nào khiến bạn thấy khó; validation error đôi khi thật sự rất bực, nên Wizard có thêm tùy chọn --trace-validation để hiển thị trực quan quá trình kiểm chứng

  • Tài liệu và binding của binaryen.js đúng là còn thiếu khá nhiều; hiện tại nỗ lực chủ yếu đang dồn vào cải thiện tối ưu hóa của core Binaryen nên phía JS/TS phát triển chậm; nhưng nếu có ai đó bỏ thời gian cải thiện binding JS/TS thì sẽ tốt cho tất cả mọi người

  • Tôi thậm chí còn thấy tự viết assembly thuần từ đầu có khi dễ hơn; đa số tài liệu đều tập trung vào công cụ Rust, nhưng trải nghiệm tự tay viết cũng rất quan trọng; compiler và assembly là hai thứ khác nhau; cũng cần nhìn từ góc độ không phải chỉ các compiler developer mới quan tâm đến Wasm

• Tôi vẫn còn nhiều kỳ vọng vào WASM, và bản phát hành lần này trông rất ấn tượng; tôi đang chạy plugin WASM lưu lượng cao trong envoy, cũng dùng WASM cho plugin của ứng dụng terminal như zellij, và trong vài dự án phụ nhỏ còn vận hành web app wasm dựa trên rust leptos; thành thật mà nói thì 2 trong 3 trường hợp có lẽ không phải lựa chọn tối ưu nhất về mặt kỹ thuật, nhưng tôi nghĩ xu hướng này sẽ tiếp tục đi lên; mọi người vất vả rồi

• Đơn giản vẫn là tốt nhất; điều tôi mong là cách truyền struct của Go dễ hơn và nhanh hơn, sao cho khi đưa struct Go vào runtime hoặc lấy ra không bị rối code và không phải dùng các giải pháp chắp vá; có giải pháp phổ quát dùng được cho nhiều ngôn ngữ thì cũng tốt, dù có đi kèm vài giới hạn thực tế cũng không sao; với tôi thì Go là quan trọng nhất

  • Tôi đồng ý với điều này, và thực tế ngay cả ở ngôn ngữ không có GC thì cũng chẳng khá hơn bao nhiêu; các runtime có GC trên wasm thực ra còn rối hơn; trải nghiệm JavaScript tệ nhất tôi từng có là phải dọn dẹp pointer thủ công; trong C++ thì ra khỏi scope là destructor lo, còn ở wasm, js thì phải tự quản hết, đến mức tôi còn thấy làm JNI ngày xưa dễ chịu hơn (kể cả với Go); rồi sau khi vật lộn truyền được một struct thì overhead mỗi lần gọi lại lớn, cuối cùng lại phải gói dữ liệu thành khối lớn hơn để chuyển; tôi cũng chỉ mong pipeline của wasm khá lên, chứ từ trước tới giờ vẫn rất vất vả

  • Nếu là native code thì cách giải quyết vẫn y hệt: hoặc thống nhất theo cấu trúc chuẩn giữa các ngôn ngữ (như C struct), hoặc serialize/deserialize; khi trộn nhiều runtime mà ngôn ngữ không hỗ trợ trực tiếp thì đúng là cực kỳ mệt, và vì sao nó thành vấn đề thì quá rõ ràng

  • Tôi không chắc chính xác bạn muốn gì, nhưng component model vốn là nền tảng của WASI có lẽ sẽ giúp được; mô hình này cho phép mỗi module tự quyết định cách ánh xạ dữ liệu vào bộ nhớ của mình (sau này cả GC heap nữa), đồng thời định nghĩa cả kiểu như struct dưới dạng interface để compiler tự sinh glue code

  • Cái này có vẻ thuộc phạm vi thư viện hơn là đặc tả WASM, tôi từng có trải nghiệm tốt với các code generator nội bộ kiểu này

• Tôi đang mong chờ hỗ trợ OpenMP; hiện tôi đang chạy thử bản build web của Solvespace, và nếu có OpenMP thì sẽ cải thiện rất nhiều demo Solvespace online, một CAD mã nguồn mở chạy trong trình duyệt

  • Tôi nghĩ Solvespace là công cụ cực kỳ hay; trước đây tôi từng theo tutorial trên YouTube để thiết kế vỏ bàn phím chia đôi rồi mang đi CNC, và ra kết quả rất nhanh; cảm ơn vì đã duy trì nó

  • Đây là web UI dựa trên WASM tốt nhất tôi từng thấy; tôi tò mò điều khó nhất khi đưa bản desktop build sang Emscripten là gì

• Thêm một ý chưa thấy ai nhắc: tôi tò mò liệu tính năng multiple-memories có thể dùng để tránh copy trùng lặp khi ánh xạ tài nguyên WebGPU hay không; hiện giờ vì dữ liệu được map vào ArrayBuffer nên phía WASM phải copy qua JS, khá bất lợi về hiệu năng; nhiều bộ nhớ WASM kết hợp với tính năng address space của Clang/LLVM có vẻ như là hướng giải quyết, nhưng tôi không chắc trên thực tế có đơn giản đến vậy không

  • Đã có thảo luận về hỗ trợ multi-memory trong toolchain, nhưng tôi không rõ liệu phía LLVM đã thực sự hiện thực cách tận dụng nhiều address space hay chưa

  • Tất cả chuyện này làm tôi nhớ tới segmented memory và far pointers ngày xưa; gần đây tôi đang viết game cho Gameboy nên việc ánh xạ bộ nhớ cũng là một phần của "niềm vui", nhưng phải lặp lại điều đó trong môi trường không bị ép buộc thì hơi ngán; việc người ta chôn luôn far pointers từ thời DOS/Win16 là có lý do cả