outside of browsers: • Wasmtime, WAMR, WasmKit, etc. • Easy to embed in applications • Useful for software that accepts untrusted programs from users • Examples: Plugin systems, serverless environments, etc. 5
developers: • If it compiles to Wasm, it can run in various environments • For platform developers: • With a Wasm runtime, it can support multiple languages Good for program distribution formats. 6
conservative GC, exceptions, and Fiber with minimal platform-specific hacks • Trade off performance and code size for portability • It greatly works for the initial stage, but we need to improve it by using recent WebAssembly features. See RubyKaigi 2022 keynote for more details https://rubykaigi.org/2022/presentations/kateinoigakukun.html 19
the core of the C-extension build system in Ruby • 3 major mkmf users (extconf.rb consumers in other words): • CRuby build system • rake-compiler • RubyGems 22
Add --target-rbconfig option to mkmf2 https://bugs.ruby-lang.org/issues/20345 $ ruby extconf.rb --target-rbconfig=path/to/rbconfig.rb creating Makefile $ make $ file nokogiri.so nokogiri.so: WebAssembly (wasm) binary module version 0x1 (MVP) 2 Will be available in Ruby 3.4 and later 23
We already support statically-linked C-extensions • But, the build model is not suitable for the RubyGems ecosystem • Take a long linking time (especially due to Asyncify) • Need to tightly integrate with the CRuby build system 26
far? • WebAssembly does not have a standard dynamic linking ABI • If we do our bespoke dynamic linking3, the binary will be incompatible with standard WebAssembly runtimes 3 Emscripten does dynamic linking by its own loader 28
concept of dynamic linking in WebAssembly • Done at the build time • The final binary is a Component • The linker is originally developed by Joel Dice in wit-component • Adjusted for Ruby use case 32
linking • The final binary, a Component, contains all the dependencies • No file-based shared library search at runtime • dlopen is available only for libraries known at build-time 33