CG, WG, W3C, Lively—Wasm standardization with Thomas Lively - WasmAssembly

Key Concepts

• Wasm GC (WebAssembly Garbage Collection): A feature allowing WebAssembly to use the browser's built-in garbage collector, avoiding the need to ship a custom one.
• Custom Descriptors: A proposal to optimize memory usage in Wasm GC by combining the user-space vtable pointer and the engine-managed internal metadata pointer into a single pointer.
• JS Interop: The ability for JavaScript and WebAssembly to seamlessly interact, including ergonomic method calls on WebAssembly objects from JavaScript.
• Shared-Everything Threads: A proposal to extend WebAssembly's threading model to share functions, tables, globals, and Wasm GC objects between threads, in addition to memory.
• VTable (Virtual Dispatch Table): A table containing pointers to methods in a class, used for dynamic dispatch.
• W3C (World Wide Web Consortium): The organization responsible for developing web standards.
• Community Group (CG): A low-barrier-to-entry group within the W3C where initial design and consensus-building for WebAssembly features occur.
• Working Group (WG): A formal group within the W3C, composed of paying members, that officially stamps and approves standards developed in the Community Group.
• Phases: Stages in the WebAssembly standardization process, indicating the maturity and stability of a proposal.
• Origin Trial: A mechanism for testing new WebAssembly features in Chrome with real-world websites.
• SharedArrayBuffer: A JavaScript object that allows multiple web workers to share memory.
• COOP/COEP Headers: HTTP headers required for using SharedArrayBuffer, ensuring cross-origin isolation.

WasmAssembly Episode 15 Summary: Thomas Lively

Introduction

Thomas Steiner interviews Thomas Lively from the V8 and WebAssembly team at Google. They discuss Lively's career path, the WebAssembly standardization process, and the proposals Lively is currently championing: custom descriptors and shared-everything threads.

Thomas Lively's Career Path

• Lively joined Google after two internships, initially working on Native Client, a predecessor to WebAssembly.
• He then transitioned to the WebAssembly team, working on the WebAssembly back end in the Rust compiler during his second internship.
• He has been with the team for nine years (including internships) or seven years (excluding internships).

WebAssembly Standardization Process at W3C

• Community Group vs. Working Group: The WebAssembly Community Group (CG) handles the entire design process and consensus-building for new features. The Working Group (WG) then rubber-stamps the CG's decisions, giving them official W3C status.
• Community Group's Role: The CG is free to join and has a low barrier to entry. It's where the full design process and consensus on new features happen.
• Working Group's Role: The WG provides the official W3C recommendation status.
• Chartering: The charter defines the deliverables of the group. It can be amended to include new types of deliverables, such as the component model or WASI.
• Active Members: While the CG has around 1,500 members on the W3C website, only about 30-35 people actively participate in bi-weekly video calls.
• Standardization Speed: The speed of standardization varies depending on the feature. It requires buy-in from JavaScript and WebAssembly engines, toolchain updates, and developer experimentation.
• Academic Influence: Academics play a significant role in the WebAssembly standards process, contributing to the design and ensuring the soundness of the type system.
• Formal Verification: Academic members focus on formal verification of the WebAssembly spec, requiring clear abstraction boundaries.
• Google's Positioning: The Chrome WebAssembly team focuses on web-related aspects of WebAssembly, while other teams at Google work on server-side and non-browser use cases.
• Web vs. Server Usage: It's difficult to estimate whether WebAssembly is currently run more on web browsers or on servers, cloud edge infrastructure, or other devices.

Custom Descriptors and JS Interop

• Problem: When compiling languages like Java to WebAssembly GC, each object instance has two pointers: one to the vtable (user-space) and one to the engine's internal metadata.
• Solution: Custom descriptors combine these two pointers into one, saving memory.
• Memory Savings: Experiments have shown a 10% reduction in memory usage in some applications.
• JS Interop Goal: To enable ergonomic method calls on WebAssembly objects from JavaScript (e.g., bar.foo() instead of WebAssembly.exports.foo(bar)).
• How it Works: Custom descriptors allow adding a field to the engine-managed metadata (Map) that points to the JavaScript prototype.
• Polyfilling: If an engine doesn't support custom descriptors, developers can ship two separate WebAssembly bundles (one with and one without custom descriptors) or fall back to JavaScript.
• JavaScript Interop Polyfill: Without custom descriptors, polyfilling JS interop is complex and inefficient, requiring wrapping WebAssembly objects in JavaScript objects and maintaining a weakmap.
• Phase: Currently in phase 2, hoping to reach phase 3 in October.

Shared-Everything Threads

• Existing Threads: WebAssembly threads currently share only memory (using SharedArrayBuffer). Everything else is separate, requiring separate instantiation of the WebAssembly module on each thread.
• Shared-Everything Threads Goal: To share functions, tables, globals, and Wasm GC objects between threads.
• Short-Term Focus: Initially focusing on shared Wasm GC structs and arrays to enable multi-threaded Wasm GC applications.
• Long-Term Benefits: Eliminates duplicated work in scenarios like dlopen in C++, where shared libraries need to be instantiated separately on each thread.
• Cross-Origin Isolation: Shared-everything threads will inherit the same cross-origin isolation requirements (COOP/COEP headers) as existing WebAssembly threads.
• Service Worker Workaround: COOP/COEP headers can be set using a service worker for development purposes.
• Code Caching: Shared-everything threads build upon existing engine optimizations for caching and sharing compiled WebAssembly code.
• Phase: Currently in phase 1. The proposal includes many features, so some parts may be split off into separate proposals to advance faster.

Wasm But Not

• Thomas Lively's Streaming Preferences: He enjoys watching "Star Wars" TV shows on Disney Plus, particularly "Andor."
• Global Set: He wishes Git and GitHub had better support for stacked PRs (small, dependent pull requests).

Contact Information

• Thomas Lively can be found on Bluesky: Tlively.bsky.social.

Conclusion

The interview provides valuable insights into the WebAssembly standardization process, the challenges and opportunities in optimizing WebAssembly performance, and the future directions of WebAssembly development. The discussion of custom descriptors and shared-everything threads highlights the ongoing efforts to improve memory efficiency and enable more complex multi-threaded applications. The emphasis on community involvement and collaboration underscores the importance of a diverse ecosystem in shaping the future of WebAssembly.