WebAssembly
WebAssembly: a low-level binary format for the web that is compiled from other languages to offer maximized performance and augments JavaScript
Advantages
- Reliable & maximized performance
- Great portability
- Since you can compile from other languages, you can share your code across deployments
- Flexibility
- You can write for the web in languages other than JavaScript
C++
Many apps used a C++ codebase through WebAssembly to enable use across platforms
(ex) SnapChat, Photoshop, WordPress, etc.
WebAssembly Debugging
C++ code made available in DevTools along with breakpoints, runtime values of variables, etc.
WebAssembly Libraries
OpenCV, TensorFlow, SQLite, etc.
How it works: WebAssembly MVP
When an app instantiates a WebAssembly module, it asks for & is allocated a region of memory for use.
Programming languages
Alloc/free languages: languages that require the developer to correctly free up dynamic memory whenever it is no longer needed
(ex) C/C++, Rust
Managed-memory languages: languages w/ runtimes that automatically scan for and free up dynamic memory when it is no longer usable
(ex) JavaScript, Java, Kotlin, Dart
Alloc/free languages
If developer is using C/C++, the WebAssembly module uses some of this memory for a dynamic heap, and the developer has to handle freeing objects on that heap.
Managed-memory languages
If the developer is using a managed-memory language, the WebAssembly module has to include the language's garbage collector code to manage the heap & automatically free up unused memory.
Problems
- Bloat
The WebAssembly module has to ship and instantiate the garbage collector every time the app is loaded, increasing the module size and delaying the application startup, despite the fact that every standard browser already contains a garbage collector for apps to use.
Also, developers need to decide how much memory to request for the modules. To avoid crashes, they typically set a maximum memory size that is just beyond the upper bound of the anticipated memory needs. This convention puts more pressure on implementations who have to manage the app's JavaScript & WebAssembly memory separately, along with the memory needed by other apps/tabs that the user may use.
- Split brain
The memories of JavaScript and WebAssembly don't know anything about each other, making developers responsible for carefully architecting their applications to avoid corruption for cases of one garbage collector freeing up memory still needed by the other's program.
However, putting all of the objects on one side, on the WebAssembly side, does not solve the problem because of web APIs. Web APIs are specified to accept and return JavScript objects, which naturally live on the JavaScript heap and are collected by the JavaScript garbage collector. In the original WebAssembly, this meant copying the data in both directions between WebAssembly and JavaScript anytime you call a web API.
Solution
New extension that in effect shares a joint heap between JavaScript and WebAssembly GC modules.
New Web Assembly GC
- Smaller binaries for managed-memory languages
- Language runtimes no longer need to ship code for garbage collection
- The host's JavaScript garbage collector will collect WebAssembly GC memory as well
- Faster interop with JavaScript code and Web APIs
- WasmGC objects can be passed by reference to JavaScript code and Web APIs like the DOM, Canvas, WebGL, and WebGPU
- This reduces the need to copy objects between the JavaScript and WebAssembly meories
- Resizable memory footprint
- Additional memory is allocated to a WasmGC module as needed
- Unused memory can be returned to the browser or the operating system for use by other apps
