WASM 3.0 fertiggestellt

 (webassembly.org)
17 Punkte von GN⁺ 2025-09-18 | 2 Kommentare | Auf WhatsApp teilen
  • Der Standard Wasm 3.0 wurde offiziell vorgestellt und umfasst große Funktionen, die über 6–8 Jahre vorbereitet wurden
  • Mit 64-Bit-Adressraum, Garbage Collection, typisierten Referenzen, Tail Calls und Exception Handling lassen sich Hochsprachen deutlich einfacher nach Wasm kompilieren
  • Die wichtigsten neuen Funktionen helfen bei Hochleistungsanwendungen, verschiedenen Sprach-Runtimes sowie Sicherheit und Erweiterbarkeit
  • Sie eignen sich nicht nur für die Web-Umgebung, sondern auch für nicht-webbasierte Ökosysteme, in denen größere Kapazitäten und Datensätze verarbeitet werden müssen
  • Unterstützung ist bereits in den wichtigsten Webbrowsern vorhanden, und auch eigenständige Engines wie Wasmtime sollen bald vollständig nachziehen, wodurch sich Wasm als allgemeine Ausführungsplattform weiter etabliert

Überblick zum Release von Wasm 3.0

  • Version 3.0 des WebAssembly-Standards wurde am 17. September 2025 veröffentlicht
    • Das ist das erste größere Update seit Version 2.0 (abgeschlossen 2022), die Vektor-Instruktionen, Bulk-Memory-Operationen, mehrere Rückgabewerte und einfache Referenztypen eingeführt hatte
    • Die W3C Community Group und die Working Group haben die Entwicklung fortgeführt; diese Veröffentlichung bringt entsprechend umfangreiche Funktionen, die 6–8 Jahre lang vorbereitet wurden, und ist damit eine recht große Änderung
    • Wasm behält seinen Charakter als Low-Level-Sprache bei, stärkt aber Speicher- und Typsystem, um die Kompilierung von Hochsprachen besser zu unterstützen
  • Funktionen, die nach Version 2.0 entwickelt wurden, sind nun abgeschlossen und als Live-Standard etabliert; die Unterstützung in Webbrowsern und eigenständigen Engines wird ausgebaut
    • Auf der Wasm-Feature-Status-Seite lässt sich der Support-Stand der einzelnen Engines verfolgen
    • Die erste Version wurde mit der neuen Toolchain SpecTec erstellt, was die Zuverlässigkeit verbessert

Wichtige Änderungen und neue Funktionen

  • 64-Bit-Adressraum
    • Speicher und Tabellen können mit dem Typ i64 deklariert werden
    • Der Adressraum von Wasm-Anwendungen kann von etwa 4 GB bis an physische Grenzen wachsen (theoretisch 16 Exabyte)
    • Im Web gilt zwar ein Limit von 16 GB, doch in nicht-webbasierten Ökosystemen ist das für große Anwendungen und Datensätze nützlich
  • Mehrere Speicherbereiche
    • Innerhalb eines einzelnen Moduls lassen sich mehrere Speicherobjekte deklarieren und direkt ansprechen
    • Das ist für das Zusammenführen von Modulen, die Trennung von Adressräumen, Buffering, Sicherheit und weitere Anwendungsfälle nutzbar
    • Statische Linker-Tools wie wasm-merge können dadurch auf alle Wasm-Module angewendet werden
  • Garbage Collection (GC)
    • Zusätzlich zum linearen Speicher wird ein vom Wasm-Runtime automatisch verwalteter Speicherbereich unterstützt
    • Compiler deklarieren Datenlayouts wie Struct-/Array-Typen und unboxed Integers direkt
    • Es werden nur die grundlegenden Bausteine für Speicherverwaltung bereitgestellt; Objektsysteme auf höherer Ebene oder Closures können je nach Implementierungssprache individuell entworfen werden
  • Typisierte Referenzen
    • Das Wasm-Typsystem wurde erweitert, um die Form von Heap-Werten und Funktionsreferenzen genauer zu beschreiben
    • Es unterstützt Subtyping und Typrekursion; mit der neuen Instruktion call_ref sind sichere indirekte Funktionsaufrufe ohne Laufzeit-Typprüfung möglich
  • Tail Calls
    • Unterstützt werden Tail-Call-Strukturen, die ohne zusätzlichen Stackverbrauch der aktuellen Funktion direkt zurückkehren
    • Das kann in funktionalen Sprachen oder für interne Optimierungen von Runtimes genutzt werden
  • Exception Handling
    • Führt ein natives Exception-Handling-System in Wasm ein
    • Es bietet Exception-Tags und Payload-Deklarationen, optionales Catching und blockbasierte Exception-Handler
    • Dadurch sind bessere Portabilität und Performance möglich, ohne bisher übliche ineffiziente Umwege über JS
  • Relaxed Vector Instructions
    • Um Unterschiede in der SIMD-Hardware zu berücksichtigen, gibt es relaxed Varianten, bei denen die genaue Ausführung mancher Instruktionen der Implementierung überlassen wird
    • Innerhalb der zulässigen Ergebnismenge sind damit verschiedene Optimierungen möglich
  • Deterministisches Profil
    • Auch in Fällen, in denen Ergebnisse für dieselbe Instruktion nicht deterministisch sein können (Floating-Point-Berechnungen, relaxed SIMD usw.), wird plattformübergreifend deterministische Ausführung definiert
    • Das kann Reproduzierbarkeit und Portabilität für Blockchains, reproduzierbare Systeme und ähnliche Szenarien sichern
  • Syntax für benutzerdefinierte Annotationen
    • Dem Quellcode wird eine für Menschen les- und schreibbare Annotationssyntax hinzugefügt
    • Sie wird vom Standard selbst nicht interpretiert, kann aber künftig für Standard- oder Erweiterungsimplementierungen genutzt werden

JavaScript-Anbindung und Kompatibilität

  • JS string builtins
    • String-Werte aus JS können als externref an Wasm übergeben und dort verarbeitet werden
    • Durch Import neuer Built-in-Funktionen lassen sich externe JS-Strings direkt innerhalb von Wasm verwenden

Nutzen und Ausblick für Wasm 3.0

  • Liefert die notwendige Grundlage für die Kompilierung fortgeschrittener Programmiersprachen nach Wasm
  • Wichtige Sprachen wie Java, OCaml, Scala, Kotlin, Scheme, Dart und weitere beginnen bereits, die GC-Funktionen aktiv zu nutzen

Stand von Spezifikation und Verbreitung

  • Wasm 3.0 ist der erste Standard, der mit der neuen SpecTec Toolchain erstellt wurde
  • Die meisten großen Webbrowser unterstützen Wasm 3.0 bereits, und eigenständige Engines wie Wasmtime sollen bald vollständig folgen
  • Auf der Seite Wasm feature status lässt sich der Support-Status je Engine prüfen

Verwandte Beiträge

2 Kommentare

 
coremaker 2025-09-18

Wird es dann nicht auch Versuche geben, eine In-Memory-Datenbank zu bauen?
 
GN⁺ 2025-09-18
Hacker-News-Kommentare

  • Ich freue mich besonders darauf, dass 64-Bit zum Standard im Spec werden; gerade Web-Apps wie Online-Videoeditoren stoßen wegen der 32-Bit-Grenze schon heute auf viele Einschränkungen, und auch bei Figma erlebt man diese Begrenzungen direkt. Eine Sache, die ich mich frage, ist, ob die Beschränkung des adressierbaren Speichers pro Tab auf Mobilgeräten bestehen bleibt. Das wird meist vom OS festgelegt und ist womöglich nicht direkt an den 32-Bit-Adressraum gekoppelt.

    • Ich frage mich, ob es wirklich richtig ist, dass Apps wie Videoeditoren in den Dokumenten-Browser wandern, obwohl es gut gemachte native Betriebssysteme gibt, die inzwischen kaum noch jemand benutzt. Wenn man eine stärkere virtuelle Maschine braucht als die Virtualisierung, die ein bestehender OS-Prozess bietet, dann wäre es ehrlicher, gleich eine dafür passende Abstraktion zu entwerfen. Es fühlt sich an, als würde man einen simplen Dokumentenleser mit Gewalt zu einem Videoeditor umbauen.

    • Leider bringt das Memory64-Feature einen ziemlich deutlichen Performance-Preis mit sich. Bei den bisherigen 32 Bit hat die Runtime jedes Mal direkt die gesamten 4 GB reserviert, sodass Bounds Checks praktisch unnötig waren; bei 64 Bit muss man die Grenzen explizit prüfen. Wenn man wirklich mehr als 4 GB Speicher braucht, muss man es wohl trotzdem verwenden.

    • Ich freue mich auch auf GC, Referenztypen und die JS string API. Ein erfreuliches J nach langer Zeit, ich hoffe, es geht ihm gut.

    • Dass Web-Apps an einer 4-GiB-Speichergrenze hängen bleiben, wirkt fast selbstverständlich. Es fühlt sich ja inzwischen an, als bräuchte man zum Lesen von E-Mails mindestens 512 GiB.

  • Es ist wirklich faszinierend, dass Garbage Collection dazukommt. Bisher konnte Wasm nicht direkt auf den Stack zugreifen, weshalb klassische GC-Ansätze wie Stack Scanning unmöglich waren. Dadurch bleibt der Charakter als Low-Level-Sprache erhalten, während man mit struct-, array-Typen und unboxed tagged ints das Speicherlayout explizit beschreiben kann und Wasm die Allokation und Lebensdauer übernimmt. Das ist schon beeindruckend.

    • Dass mit GC zugleich eine Struktur entsteht, die auch Nicht-GC-Umgebungen unterstützt, finde ich spannend. Das erinnert an die Sprache D, die sowohl ohne GC als auch mit GC schnelle Kompilierung und Ausführung unterstützt. Übrigens kann man mit dem Dlang-Compiler LDC inzwischen auch Wasm erzeugen: Generating WebAssembly with LDC

    • Ich frage mich, ob diese Änderung es erlaubt, die Größe von WebAssembly.Memory-Objekten zu reduzieren. Dass Speicher nach dem Freigeben weiterhin im Browser allokiert bleibt, ist ein sehr wichtiges Thema. Issue 1 Issue 2

  • Ich frage mich, wann WASM den DOM direkt anfassen kann. Das wirkte ursprünglich wie der eigentliche Kernzweck von WASM, während es sich jetzt wie ein separates Monster anfühlt, das mit dem Web fast nichts mehr zu tun hat. Ich frage mich, wann man JavaScript endlich nicht mehr brauchen wird.

    • Ich hoffe, dass dieser Bereich und auch der Multithreading-Zugriff richtig unterstützt werden. Ich würde gern eine Rust-App schreiben, zu Wasm kompilieren und dann direkt so einbinden:

      Für High-Performance-Web-Apps oder Browser-Erweiterungen sind Speicher- und Performance-Probleme tatsächlich groß, daher wäre das extrem hilfreich. Bei Wasm-basierten Apps könnte man v8 überspringen und Engines wie Wasmer direkt verwenden. Dass Web-Technologien für Desktop-Apps wie Electron genutzt werden, liegt meiner Meinung nach daran, dass Desktop-APIs zu schlecht und nicht portabel genug sind. Wenn die native Unterstützung für WASM stärker wird, könnten Apps wie Slack, VSCode und Discord leichter werden.

    • Auch jetzt ist DOM-Zugriff aus WASM-Programmen möglich. Man muss nur über die bestehenden JS-APIs gehen. Es gab einmal Diskussionen über eine dedizierte WASM-API, aber wegen zu vieler Nachteile wurde das letztlich verworfen.

    • Ich beobachte die Lage weiter und warte auf eine gut entworfene Frontend-Sprache. Allerdings frage ich mich, ob der Umweg über JS-Wrapper beim DOM-Zugriff wirklich so ineffizient ist. Der meiste Code ist ohnehin schon ineffizient, daher fällt der Overhead in der Praxis meiner Meinung nach kaum auf.

    • Wenn du denkst, JavaScript habe Probleme, dann wirst du feststellen, dass es beim DOM noch schlimmer aussieht.

    • Sobald man DOM-Referenzen halten kann, wird es knifflig, weil man dann potenziell direkt auf Objekte mit Garbage Collection blickt. Im Sicherheitsmodell von Web-JavaScript darf man die Interna des GC nicht einsehen. Wenn WASM also Pointer auf den DOM hält, ist die Frage, wie das behandelt werden soll. Sobald GC ordentlich eingeführt ist, kann man das vielleicht erneut diskutieren, aber für WASM ohne GC wirkt das fast unlösbar.

  • Ich habe die WASM-Entwicklung etwa ein Jahr lang nicht verfolgt und erfahre erst jetzt, dass man zu einem Release-Modell nach Versionen übergegangen ist. Ich hatte erwartet, dass viele Features optional bleiben würden, aber jetzt scheint es so zu sein, dass eine Implementierung nur dann als kompatibel mit einer bestimmten Version gelten kann, wenn sie alle Features unterstützt, etwa bei WASM 3.0. Zweitens frage ich mich, welche Non-Browser-Runtime als zweite vollständige 3.0-Unterstützung liefern wird; ich vermute, Wasmtime wird die erste sein, Deno zählt wegen v8 nicht. Gerade GC wirkt wie ein besonders kniffliges Feature. Weiß jemand, wie sich das 3.0-Release mit dem bisherigen "evergreen"-Modell verbindet? Evergreen bedeutet ja, dass man Standard-Entwürfe fortlaufend aktualisiert, ohne eine gesonderte finale offizielle Version zu haben. Der aktuelle Candidate Recommendation Draft gilt faktisch als Standard. Wasm-Feature-Status Neuigkeiten zu Wasm 2.0 Aktueller Standardentwurf

    • Wasmtime unterstützt bereits alle wichtigen Features von Wasm 3.0. GC wurde vor einigen Jahren von meinem Kollegen Nick Fitzgerald implementiert, Tail Calls wurden letztes Jahr von Jamey Sharp und Trevor Elliott vollständig umgesetzt, also ohne Signaturbeschränkungen und ohne Bedarf an Trampolines. Auch Exception Handling ist fertig und wird bald offiziell veröffentlicht. Das Release "3.0" kann man als Signal verstehen, dass die Engines die einzelnen Features ohnehin schon vorbereitet hatten. Ich bin Maintainer von Wasmtime und Cranelift.

    • Wizard ist ein Tool für Forschungszwecke, unterstützt aber vollständig Wasm 3.0. Es hat allerdings nur einen Interpreter und einen Baseline-Compiler, keinen optimierenden Compiler wie v8 oder Wasmtime. Deshalb ist es eher langsam.

    • Das Versionsmanagement wird vermutlich eher wie bei JavaScript über Feature Sets laufen, also darüber, welche Funktionsmenge eine Runtime unterstützt. Ich frage mich, wie Feature Discovery bei Wasm eigentlich funktioniert.

  • Ich freue mich wirklich über die hinzugekommene GC-Unterstützung. Früher war eine klassische stack-scanning-basierte GC-Implementierung in WASM praktisch unmöglich, weil man nicht direkt auf den Stack zugreifen konnte.

  • Ich finde, die WebAssembly-Community sollte mehr auf die Developer Experience (DX) achten. Ich habe selbst einmal einen Compiler geschrieben, der Wasm als Ziel hatte, und das war ziemlich unbequem. Ich dachte, es sei eine Sprache mit streng definierter Semantik, aber tatsächlich fühlte es sich beim Erzeugen von Wasm mit Binaryen.js nicht so an, als würde man auf ein klar umrissenes Instruction Set zielen. Wahrscheinlich liegt das an Binaryen selbst und an der dürftigen Dokumentation. Ein kleiner Trost war, dass es Spaß gemacht hat, Wasm-Text-Snippets zu schreiben. Jasmine-Wasm-Compiler

    • Binaryen trägt viel Altlast mit sich herum, weil frühes Wasm AST-basiert war. Neue Features lassen sich nur schwer in das bestehende Modell einpassen. Unser Compiler definiert deshalb eine eigene Datenstruktur für eine abstrakte Wasm-Repräsentation und gibt standardmäßig .wasm, zum Debuggen aber .wat aus. Ich finde das ziemlich intuitiv, deshalb halte ich das Instruction Set an sich für in Ordnung. Scala.js Wasm-Backend

    • Ich hatte ein ähnlich frustrierendes Erlebnis, als ich Binaryen aus TypeScript heraus verwendet habe. Danach bin ich zu den Rust-basierten wasm-tools gewechselt, und das war deutlich angenehmer.

    • Mich würde interessieren, was konkret schwierig war. Validation Errors können wirklich nervig sein, deshalb hat Wizard auch eine Option --trace-validation, die den Validierungsprozess übersichtlich visualisiert.

    • Die Dokumentation und Bindings von binaryen.js sind tatsächlich ziemlich schwach. Im Moment konzentriert sich die Arbeit eher auf Optimierungsverbesserungen im Core-Binaryen, daher entwickeln sich JS/TS-Seite und Bindings nur langsam. Trotzdem wäre es für alle hilfreich, wenn jemand Zeit in bessere JS/TS-Bindings investieren würde.

    • Es fühlte sich für mich auch so an, als wäre es einfacher, reinen Assembler-Code direkt von Grund auf zu schreiben. Die meisten Materialien konzentrieren sich auf Rust-Tools, aber die Erfahrung, Dinge von Hand zu schreiben, ist ebenfalls wichtig. Compiler und Assembly sind getrennte Themen. Man braucht auch die Perspektive, dass sich nicht nur Compiler-Entwickler für Wasm interessieren.

  • Ich habe weiterhin Erwartungen an WASM, und dieses Release sieht großartig aus. Ich betreibe in Envoy stark frequentierte WASM-Plugins und nutze WASM auch für Plugins von Terminal-Apps wie Zellij. In kleineren Side Projects läuft bei mir außerdem eine auf Rust Leptos basierende Wasm-Web-App. Ehrlich gesagt sind zwei von diesen drei Einsätzen technisch vielleicht nicht die optimale Wahl, aber ich glaube, dass sich diese Richtung künftig gut weiterentwickeln wird. Gute Arbeit an alle.

  • Einfach ist am besten. Mein Wunsch ist ein leichterer und schnellerer Weg, Go-structs zu übergeben. Wenn man Go-structs in eine Runtime hinein- oder herausgibt, sollte sich der Code nicht verheddern, und man sollte keine aufgesetzten Lösungen brauchen. Eine allgemeine Lösung, die für mehrere Sprachen taugt, wäre gut, aber auch realistische Einschränkungen wären für mich okay. Für mich ist Go am wichtigsten.

    • Dem stimme ich zu, und in Sprachen ohne GC ist es in der Praxis auch nicht viel besser. Tatsächlich sind GC-freie Runtimes in Wasm oft sogar noch chaotischer. Die schlimmste Erfahrung, die ich bisher mit JavaScript gemacht habe, war manuelles Pointer-Aufräumen. In C++ kümmern sich Destruktoren darum, sobald der Scope verlassen wird, aber in Wasm und JS muss man alles selbst verwalten, sodass mir sogar meine JNI-Erfahrungen lieber waren, auch bei Go. Und wenn man sich dann endlich durchgekämpft hat, um ein einziges struct zu übergeben, ist der Overhead pro Aufruf so hoch, dass man am Ende anfängt, größere Pakete auf einmal zu überreichen. Ich hoffe ebenfalls, dass bei Wasm zumindest die Pipeline besser wird. Bisher war es mühsam.

    • Bei nativem Code ist die Lösung dieselbe: Entweder man richtet sich sprachübergreifend nach einer Standardstruktur wie C-structs, oder man serialisiert und deserialisiert. Wenn man mehrere Runtimes mischt und die Sprachen das nicht direkt unterstützen, wird es wirklich unerquicklich. Warum das ein Problem ist, liegt auf der Hand.

    • Ich weiß nicht genau, was du dir wünschst, aber das Component Model, auf dem WASI basiert, dürfte helfen. In diesem Modell legt jedes Modul selbst fest, wie es Daten im Speicher abbildet, später möglicherweise sogar im GC-Heap, und Dinge wie struct-Typen werden als Interface beschrieben, sodass Compiler den Glue Code automatisch generieren können.

    • Das klingt für mich eher nach einem Bibliotheksthema als nach einem Teil des WASM-Specs. Ich habe intern gute Erfahrungen damit gemacht, solche Codegeneratoren einzusetzen.

  • Ich freue mich auf OpenMP-Unterstützung. Ich experimentiere mit einem Web-Build von Solvespace, und mit OpenMP-Unterstützung wäre das ein großer Gewinn. Online-Solvespace-Demo, ein Open-Source-CAD, das im Browser läuft.

    • Ich finde Solvespace wirklich ein großartiges Tool. Ich habe vor einiger Zeit mithilfe eines YouTube-Tutorials ein Gehäuse für eine geteilte Tastatur entworfen und per CNC gefertigt. Man kam sehr schnell zu Ergebnissen. Danke, dass du es pflegst.

    • Das ist für mich die beste WASM-basierte Web-UI, die ich bisher gesehen habe. Mich würde interessieren, was beim Portieren des Desktop-Builds mit Emscripten am schwierigsten war.

  • Ich lasse noch etwas da, das bisher nicht erwähnt wurde: Ich frage mich, ob das multiple-memories-Feature genutzt werden könnte, um beim Mapping von WebGPU-Ressourcen doppelte Kopien zu vermeiden. Aktuell gibt es ein Mapping auf ArrayBuffer, daher muss WASM über JS kopieren, was leistungsmäßig nachteilig ist. Mehrere WASM-Memories zusammen mit der Address-Space-Funktionalität von Clang/LLVM wirken wie eine mögliche Lösung, aber ich bin mir nicht sicher, ob es in der Praxis wirklich so einfach ist.

    • Es gab zwar eine Diskussion über Toolchain-Unterstützung für Multi-Memory, aber ich weiß nicht, ob in LLVM tatsächlich schon eine Implementierung existiert, die mehrere Address Spaces nutzt.

    • Das alles erinnert mich an frühere segmented memory und far pointers. Ich programmiere gerade wieder ein Gameboy-Spiel, deshalb gehört Memory Mapping für mich teilweise zum "Spaß" dazu, aber in einer Umgebung ohne solche Zwänge möchte ich das nicht noch einmal durchleben. Dass man far pointers aus der DOS/Win16-Zeit begraben hat, hatte gute Gründe.