WebAssembly 3.0: що дають 64-бітна пам’ять, збирач сміття та нові типи посилань

WebAssembly 3.0 став новою чинною версією стандарту у вересні 2025 року. Він додав 64-бітну адресацію пам’яті, кілька пам’ятей у модулі, збирач сміття, типізовані посилання, хвостові виклики та власну обробку винятків. Оновлення помітно розширює набір мов і застосунків, які можна компілювати у Wasm, але підтримка конкретної функції все одно залежить від браузера, автономного рушія та інструментів.

Wasm залишається переносним форматом виконання

WebAssembly — це компактний бінарний формат і формальна модель виконання. Браузери використовують його поруч із JavaScript, а автономні рушії запускають модулі на сервері, периферійних пристроях і в плагінних системах. Стандарт визначає семантику модуля, але доступ до файлів, мережі чи інтерфейсу надає середовище через імпорти або системні API.

Версія 3.0 не перетворює Wasm на операційну систему й не гарантує, що будь-яку програму можна скомпілювати без змін. Вона дає компіляторам нові низькорівневі можливості, на яких вони будують підтримку конкретних мов.

Memory64 прибирає межу 4 ГіБ

Раніше адреси лінійної пам’яті Wasm були 32-бітними, що обмежувало адресний простір приблизно 4 ГіБ. Memory64 дозволяє використовувати i64 як тип адреси. Теоретичний простір значно більший, хоча фізичні ресурси й політики середовища залишають практичні межі.

Офіційне оголошення зазначає, що у вебі 64-бітна пам’ять обмежується 16 ГіБ. Автономні рушії можуть підтримувати більші обсяги. Функція важлива для великих наборів даних, баз, наукових застосунків і перенесення програм, які розраховують на 64-бітні вказівники.

64-бітна адресація має ціну

Більші вказівники збільшують структури даних і тиск на кеш. Якщо застосунку достатньо сотень мегабайтів, перехід на memory64 не обов’язково покращить продуктивність. Інструментарій має узгодити ABI, бібліотеки та модель пам’яті, інакше модулі з різними припущеннями не з’єднаються.

Потрібно також перевірити, чи рушій справді підтримує потрібний режим у цільовій версії. Коректний модуль Wasm 3.0 може не запускатися в старішому середовищі, тому матриця сумісності залишається частиною релізу.

Кілька пам’ятей посилюють ізоляцію всередині модуля

Wasm давно дозволяв застосунку працювати з кількома об’єктами пам’яті через різні модулі. Версія 3.0 дозволяє одному модулю оголошувати та безпосередньо використовувати кілька пам’ятей, включно з копіюванням між ними.

Це корисно для статичного об’єднання модулів, розділення приватних даних, буферів або інструментування. Але окремі пам’яті не є автоматичною межею безпеки. Компілятор і хост повинні контролювати імпорти, експорт та операції копіювання.

Wasm GC орієнтований на компілятори мов

Збирач сміття в Wasm 3.0 не додає готову об’єктну модель Java чи Kotlin. Стандарт надає структури, масиви, типізовані посилання й керування часом життя. Компілятор сам визначає представлення об’єктів, таблиць методів, замикань і значень вихідної мови.

Раніше керовані мови часто приносили власний збирач сміття всередину лінійної пам’яті, збільшуючи модуль і дублюючи роботу рушія. Wasm GC дозволяє краще інтегрувати керовані об’єкти з хостом. Саме тому розширилася практична підтримка Java, Kotlin, Scala, Dart, OCaml та інших мов.

Типізовані посилання зменшують частину перевірок

Новий типізований механізм описує форму значення в купі, підтримує підтипи й рекурсивні типи. Функціональні посилання можуть викликатися через call_ref із перевіреною сигнатурою. Це дає компілятору більше інформації та зменшує потребу в деяких динамічних перевірках.

Водночас типова безпека Wasm не перевіряє бізнес-логіку і не захищає від надмірного споживання ресурсів. Хост усе ще повинен обмежувати пам’ять, час виконання, імпорти й кількість екземплярів.

Винятки більше не повинні виходити через JavaScript

Wasm 3.0 має нативні теги винятків, інструкції throw та блоки обробки. До цього компілятори часто моделювали винятки через переходи або виклики хоста, що ускладнювало переносимість і могло погіршувати продуктивність.

Нативна модель краще відповідає мовам із try/catch, але не робить помилки дешевими чи безпечними. Контракт на межі компонентів має визначати, які винятки перетинають модуль, як очищаються ресурси та що бачить хост.

Хвостові виклики допомагають функціональним мовам

Хвостовий виклик передає керування наступній функції без збереження поточного кадру стека. Це дозволяє реалізувати глибоку рекурсію та деякі внутрішні механізми компілятора без постійного зростання стека. У Wasm 3.0 підтримуються прямі й непрямі хвостові виклики.

Проте компілятор повинен явно їх генерувати, а рушій — підтримувати. Звичайний виклик у хвостовій позиції не обов’язково автоматично стане оптимізованим у кожному ланцюгу інструментів.

Детермінований профіль має окреме призначення

Розслаблені SIMD-інструкції дозволяють використовувати ефективні апаратні варіанти з обмеженим набором допустимих відмінностей. Для блокчейнів, повторюваних обчислень та систем відтворення це може бути неприйнятно. Тому стандарт визначає детерміновану поведінку для операцій, де можливі різні результати.

Детермінізм потрібно вимагати й тестувати як профіль середовища. Сам факт використання Wasm не гарантує побітової однаковості результатів, якщо хостові функції читають час, випадковість, мережу або зовнішній стан.

Як оцінити готовність до Wasm 3.0

• Визначте мінімальні версії браузерів та автономних рушіїв.
• Перевірте таблицю підтримки кожної потрібної функції.
• Зафіксуйте версію компілятора, лінкера, runtime та системного API.
• Тестуйте обмеження пам’яті й поведінку при вичерпанні ресурсів.
• Перевірте винятки та очищення ресурсів на межі модуль–хост.
• Вимірюйте розмір завантаження, час компіляції та пікову пам’ять.
• Зберігайте резервний шлях для старіших середовищ, якщо він потрібен аудиторії.

Wasm 3.0 не замінює контейнери

Контейнер упаковує процес із файловою системою та залежностями операційного середовища. Wasm-модуль працює в компактнішій моделі з явно наданими можливостями. Вони можуть доповнювати одне одного: контейнер запускає Wasm-рушій, а модулі забезпечують плагіни або ізольовані функції.

Матеріал TechPulse про Docker допомагає порівняти межі упаковки. Стаття про відтворювані збірки корисна для ланцюга постачання Wasm-модулів: формальна переносимість формату не доводить походження конкретного бінарного файла.

Головна цінність Wasm 3.0 — не одна сенсаційна функція, а зріліша платформа для компіляторів. Вибирати нові можливості варто за потребою застосунку й реальною підтримкою цільових середовищ, а не лише за номером стандарту.

Першоджерела: офіційне оголошення Wasm 3.0 та сторінка специфікацій WebAssembly.